Some help with PolicyKit basics

[Robert Ancell]

Thanks David,

> The code doesn't really compile without mirror.h...

Whoops, attached.  Note that the program is not interesting in itself,
rather that it is using PK correctly.

> First you appear to be mixing the new PolicyKit version with the old one
> (the server links against polkit-gobject-1, the client against
> polkit-dbus). In the new PolicyKit, with version > 0.90) the client is
> not supposed to know anything about PolicyKit at all - it simply invokes
> methods on the server and the server simply does authorization checks
> using polkit. If the server passes ALLOW_USER_INTERACTION to polkit it
> means that Authentication Dialogs may appear - but the client would
> never need to know anything about this. In fact, the client itself
> _cannot_ even speak to PolicyKit - it is not allowed.

OK, that makes it clear.  I was looking through existing PK client code.

> It is not clear to me what exactly you are trying to achieve - are you
> trying to do stuff that works like the OS X lock?

Yes, a lock.  I think this is required for any configuration dialog as
the UI may not be able to show the configuration until the client is
authorized and the user doesn't want to authorize for each config
change.

I think I understand better, does this make sense (in the case of a
simple PK+DBUS client/server):

- PK clients do not need any knowledge of PK, they make D-BUS calls
and the user will be prompted for any required authorization.  During
authorisation the D-BUS call will block until authorisation is
received or denied.

- The way a PK client knows a call failed due to authorization is by
checking the DBusError returned from a failed call.

- The PK server checks authorization in each D-Bus handler using
polkit_authority_check_authorization_sync() using the D-Bus name for
the client.

- To avoid the client having to enter their password for each D-Bus
call the server should maintain a list of authorized D-Bus names.
This is safe because D-Bus guarantees these names to be unique (Is
this still true if the d-bus daemon is restarted?)

- To provide an "unlock" feature the server needs to provide a method
which tells the client if it is authorized and a method that does that
performs authorization (but no other actions).

Thanks,
--Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mirror.h
Type: text/x-chdr
Size: 849 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20090727/7031621f/attachment.h