PolicyKit, KDE, Qt, and integration

[David Zeuthen]

On Tue, 2009-05-26 at 18:14 +0200, Dario Freddi wrote:
> > There's some GObject-based classes and interfaces in
> > libpolkit-agent-1.so (source is in src/polkit-agent) that makes all this
> > very easy (including abstracting all the PAM bits) but you can also just
> > use the D-Bus interfaces if you want to avoid that dependency.
> 
> Shouldn't the DBus interface just be a different interface for that library? 
> If not, please consider doing so - it would be a shame to have a DBus 
> interface that is not covering all the ease of use of the library - or I 
> misunderstood you. If I got it well, I'll try and prepare a patch if there are 
> additional advantages in polkit-agent

But it's the other way around, the D-Bus interfaces are what the daemon
exposes. The libpolkit-agent.so is just a small library that provides

 - a helper class, PolkitAgentListener
   http://people.freedesktop.org/~david/polkit-HEAD/PolkitAgentListener.html
   to register with the PolicyKit daemon.

   This is just a glorified way of calling RegisterAuthenticationAgent()
   and handling incoming requests on the org.fd.PK1.AuthenticationAgent
   interface. Oh, and it handles reconnection attempts as well - which
   is useful for hacking on the polkit daemon and also makes things
   appear as if they are working should the polkit daemon crash (it will
   be reactivated on the bus)

 - another helper class, PolkitAgentAuthenticationSession
   http://people.freedesktop.org/~david/polkit-HEAD/PolkitAgentSession.html
   that is more complex since it does all the PAM stuff for you
   including using a setuid root helper that calls into the PolicyKit
   daemon to do AuthenticationAgentResponse().

Keep in mind that PolicyKit proper does not care about PAM at all; in
fact, the authentication agent could be a simple program that just
provides an user experience with simple "Deny/Confirm" buttons instead
of requiring authentication. 

This is actually _a good thing_ since for some devices you want a user
experience like that (e.g. "Deny/Confirm" instead of passwords etc.). It
also allows us to switch to a more modern authentication stack than PAM
should we ever get one.

I agree it would be a lot of work to reimplement this just to get rid of
the libpolkit-agent-1.so dependency. Then again, I don't see why it
would be a problem to use this code in KDE since a) your authentication
agent would be a separate application; and b) all the deps are on the
disk anyway since they are also used in the PolicyKit daemon proper
(except for PAM but that is very likely to be on the disk).

> 
> >
> > I think you really want the KDE specific bits to live in the KDE repos;
> > I certainly want the GNOME specific bits to live in the GNOME repos so I
> > can get updated translations and so forth. Once PolicyKit 1.0 is out the
> > API won't change so you shouldn't need to change authentication agents
> > at all.
> 
> Great to hear that you're aiming for binary compatibility.

I should clarify here. I don't plan to break the libpolkit-agent-1.so
interface once 1.0 is out, not without an so-name-bump anyway. 

But we might want to break it if something better than PAM comes along.
But since libpolkit-agent-1.so is a small library, it shouldn't be very
painful and so-name-transitions is a pretty well-understood thing
anyway. 

And, FWIW, I don't expect there will be a PAM replacement for a long
time anyway.. which is too bad, because PAM really has annoying
limitations like multi-factor authentication.. But, oh well, I digress.

> > Also note that one change in PolicyKit 1.0 is that e.g. desktop apps
> > (such as a file manager) will not need to know that the mechanism (such
> > as DeviceKit-disks) they are using are using PolicyKit at all. This is
> > because mechanisms now use calls on the PolicyKit daemon that makes the
> > authentication dialogs pop up and disappear as appropriate.
> 
> So the authentication is completely abstracted in the mechanism and everything 
> happens in it? That sounds really like good stuff :)

Right, this is how PolicyKit 0.9.x works

http://hal.freedesktop.org/docs/PolicyKit/diagram-interaction.png

e.g. the desktop app needs to poke the authentication agent itself.
Works great but means there's a lot of work needed in each app.

Parden my ASCII art (I need to write proper docs for polkit 1.0, so this
will have to do for now), this is how PolicyKit 1.0 works (where p-a-h-1
is the setuid root authentication helper used by libpolkit-grant-1.so):

+--------------+        +----------------------+      +---------+
| File Manager |        | Authentication Agent | <--> | p-a-h-1 |--\
+--------------+        +----------------------+      +---------+  |
     ^   |                             ^              |   PAM   |  |
     |   |                             |              +---------+  |
6.OK |   |                             |                           |
     |   | 1. Mount()                  | 3. BeginAuthentication()  |
     |   |                             |                           |
     |   |                             |                           |
     |   |                             |                           |
     |   V                             |                           |
+-----------------+ 2. CheckAuthz() +-------------------+          |
|                 |---------------->|                   |          |
| org.fd.DK.Disks |                 | org.fd.PolicyKit1 |          |
|                 |<----------------|                   |          |
+-----------------+  5. Authorized  +-------------------+          |
                                          ^                        /
                                          \------------------------
                                     4. AuthenticationAgentResponse()


One main difference here is that call number 1., Mount(), might block a
long time while the authentication is happening. So apps like a file
manager need to cope with that. But file managers already needs to cope
with stuff like that since it's an IPC call.

But, anyway, as you can see the file manager (e.g. Nautilus or Dolphin)
won't have to know anything about PolicyKit at all. Same goes for every
other user of PolicyKit.... just simpler all around.

Hope this clarifies.

     David