Re: Using GSettings to set for all users


(It would probably be good to open a bug about this instead of doing
it on a mailing list...)

Here's a couple of comments. First, there's an assumption hard-wired
into all of this that polkit works like this

 - Obtain an authorization to do XYZ
 - actually do XYZ

while that's actually not true. The way polkit works is described here

Also, your mail about how this will work with polkit is a bit
hand-wavy at this point - I think it would help to prototype it before
proposing or discussing API additions.

Indulge some rambling about polkit: Given an action id XYZ, a
Mechanism typically want to inquire whether a Caller (or Client) is
authorized - there are three possibilities

 - The Caller is already authorized for XYZ.

 - The Caller is not authorized for XYZ and an authorization cannot
   be obtained

 - The Caller is not authorized for XYZ and an authorization can be
   obtained by authenticating the user.
   - the obtained authorization is either one-shot or it is temporary

At this point, already, we need to identify what the Caller and what
the Mechanism is.

Clearly, the Caller is the GSettings-using app, e.g. typically an
unprivileged GTK+ preference dialog or whatever.

The Mechanism here is dconf which obviously is privileged since it can
write to the defaults area (doesn't that it is uid 0, just means that
it has additional (or different if you want) privileges than the
Caller. E.g. if not uid 0, it runs with a fixed uid, e.g. a uid for
the username "dconf" or something.).


 - You need to think about the polkit action id's and mention how this
   can be overridden the same way it works in gconf, e.g. similar to
   org.gnome.gconf.defaults.policy and

   $ grep -1 annotate
    <annotate key="org.gnome.gconf.defaults.set-system.prefix">/desktop/gnome/background</annotate>

   e.g. for keys prefixed with /desktop/gnome/background, the
   org.gnome.control-center.defaultbackground polkit action id
   is used.

   Or more succinct: please do look at how the work Matthias
   already did for gconf and consider just copying that!

 - Calls into polkit that causes an authentication dialog to be shown
   (e.g. code that passes the ALLOW_USER_INTERACTION flag)
   needs to come from a Privileged Component so the you can set the
   GSettings key-name in the @details argument of CheckAuthorization().
   This allows apps to ship a PolkitBackendActionLookup extension so
   they can override the contents of the authentication dialog.

   Note that you can still have unprivileged code _check_ the
   authorization without setting the @details argument as long as you
   don't pass the ALLOW_USER_INTERACTION_FLAG. This is what
   you want to use in the client-side implementation of, say,

   (Btw, g_settings_canhasprivs() with polkit *will* involve a D-Bus
   call to the polkit Authority so you need the _sync, _async and
   _finish() variants... unless you rethink the API. I don't know)

   (Also: right now "Privileged Component" means uid 0. But as I
   said yesterday on IRC, I'm going to make it possible to make e.g.
   dconf drop a file somewhere so unix-user "dconf" (or "nobody",
   or "whatever"...) is also allowed to pass non-empty @details).

Hope this helps.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]