Some help with PolicyKit basics

[David Zeuthen]

On Tue, 2009-07-28 at 17:42 +1000, Robert Ancell wrote:
> >> - 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?

What action are you using? 

You need an action where the authorization can be retained, e.g. you
need to use an action with one of the implicit authorizations being

 AuthenticationRequiredRetained
 AdministratorAuthenticationRequiredRetained

and not just

 AuthenticationRequired
 AdministratorAuthenticationRequired

cf

http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-enum-ImplicitAuthorization

For example running the example with the action id
org.freedesktop.policykit.example.pkexec.run-frobnicate should work...

Hmm, we should probably return some information in the PolkitDetails
object so we can have this method

 polkit_authorization_result_get_retains_authorization()

just like we already have

 polkit_authorization_result_get_is_authorized()
 polkit_authorization_result_get_is_challenge()

and then only allow unlocking the PolkitLockButton if this condition

 (polkit_authorization_result_get_is_challenge() &&
  polkit_authorization_result_get_retains_authorization())

is true. I'll add that.

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

Sounds like a bug to me.

    David