Some help with PolicyKit basics

Robert Ancell robert.ancell at gmail.com
Tue Jul 28 00:42:43 PDT 2009


>> - 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
>
> Now, a Mechanism _may_ cache the results authorization checks but it
> really shouldn't unless performance is a concern. If it does cache the
> results it should evict that cache upon receiving the Changed signal
> from the Authority. And a Mechanism can never cache an authorization
> unless it is a temporary one (look for polkit.temporary_authorization_id
> in the returned details). So, all in all, Mechanisms should never cache
> authorization results.

> PolicyKit itself has the notion of temporary authorizations precisely to
> avoid the user having to authenticate over and over again. There is
> enough API available such that UI bits can display visual indication if
> something in the user session has one or more temporary authorizations.

OK, this is the bit that doesn't seem right to me.

When I run the example program I attached it prompts for a password
when I press unlock, and each time I activate the GtkEntry (i.e. for
all D-Bus calls).  I was expecting it to only ask the first time and
then work for the next n minutes (like sudo).  Is this a configuration
issue?  Are there any PolKit logs where I can see what PolKit is
deciding?

It also times out authorizing on the third attempt - does this sound
like a bug or a feature?

--Robert


More information about the polkit-devel mailing list