PolicyKit, KDE, Qt, and integration

[Dario Freddi]

On Tuesday 26 May 2009 19:04:35 David Zeuthen wrote:
> 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
>
>[...]
>
> 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.

Ok, cool stuff

>
> 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 am just looking for a confirmation that this library is here to stay. We're 
about to face a rewrite because of polkit-dbus and polkit-grant being 
deprecated, and I really want to avoid such a thing again if not in some 
years. If you tell me I can count on polkit-agent, then there is not a problem 
in using it in KDE.

> >
> > 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.

Ok, that at least is good

>
> 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.

My 2 cents: why not switching to a backend system? It would definitely make 
the transition easier, should the case happen, and will save you a lot of 
possible future work and binary compatibility of polkit-agent. I volunteer for 
helping you: if you're interested in such a thing, this is definitely the 
right time.

> > 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()
>

Nice picture, definitely :)

>
> 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.

Ok, then I definitely understood you well in the last mail, and I can just 
repeat that this change is much appreciated :)

>
> Hope this clarifies.
>
>      David

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20090526/3b20607f/attachment-0001.pgp