auth_admin_keep_always discrepancy

[David Zeuthen]

Hey,

I didn't see this message until now.

On Fri, 2009-09-04 at 13:15 +0100, James Westby wrote:
> Hi,
> 
> It's come to my attention that there seems to be a discrepancy in the meaning
> of auth_admin_keep_always between the GNOME and KDE agents (old polkit).
> 
> GNOME seems to treat it as "allow the user to choose to store the authorization
> for ever", whereas KDE seems to treat it as "default to storing the
> authorization for ever", which introduces serious difficulty in choosing which
> to use. Similar discrepancies seem to occur for keep_session and the non-admin
> cases.
> 
> http://hal.freedesktop.org/docs/PolicyKit/PolicyKit.conf.5.html states:
> 
>   auth_admin_keep_always
>     Access denied, but authentication of the caller as an administrative
>     user will grant access any caller with the given uid in the future. 
> 
> which isn't entirely clear.
> 
> The agents should unify on this (though this version of polkit is almost
> deprecated), so which interpretation is correct?
> 
> Is there a similar ambiguity in polkit-1?

In polkit1, the gnome authentication agent doesn't give you a choice
whether the authorization should be retained and the API doesn't allow
for it either. So all authentication agents should behave the same with
polkit1.

Also note that authorizations that are obtained and retained expire
after five minutes and cannot be used outside the process it was
obtained for. On top of that, a notification icon lets the user easily
drop the obtained authorization, see

 http://people.freedesktop.org/~david/polkit-tmp-authz.png

Also, if the process that the authorization was obtained and retained
for exits, the authorization is effectively lost and the icon disappears
(assuming no other process is holding a temporary authorization). W

e could improve this notification icon by, when clicked, popping up a
list of temporary authorizations currently held by processes in the
session.. the API allows for this but I didn't do it this way because
it's a bit overkill. We might (or might not) want to change that in the
future. I don't know.

     David