>> - 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 _______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
