libhal-policy -> PolicyKit

[David Zeuthen]

On Wed, 2006-03-08 at 12:59 -0800, Artem Kachitchkine wrote:
> > I indeed want PolicyKit to be able to auth the user against his own
> > password instead of the root password and
> 
> Then how would he be able to modify the policy? If an agent does it for 
> him, then, indeed, as you say "allowing users to permanently acquire a 
> privilege should probably be another privilege in itself" and is it 
> something that a sane sysadmin would allow? How does he limit which 
> privileges does he have a privilege to acquire? Is there really a 
> fundamental difference between temporary and permanent, or a kind of 
> difference we want to maintain? All sorts of difficult questions arise 
> from such recursion.

Each policy should probably have a "allow authorized users to
permanently grant this privilege to self or other users" boolean.

> > But I also don't want a situation where things are not
> > fixable for a user unless the sys admin explicitly configured the system
> > for this. That's just bad and leaves the user in the cold.
> 
> Well, I understand the problem, but not the solution. What bothers me is 
> the dangerous dance we perform with D-BUS auth, PAM, PolicyKit's own 
> policies and system-wide policies (which are so different in different 
> OSes).
> 
> Perhaps we could improve configuration tools instead? E.g. when the user 
> installs a system and says "This is a personal system and the only 
> sysadmin here is me", then when a privilege is missing, launch an 
> administration GUI du jour, passing the privilege name, so the GUI does 
> the smart thing brings the user directly to it. Of course, following you 
> description, I could patch libpolkit-GNOME in Solaris to do exactly 
> that, but that kind of makes GNOME experience less coherent across 
> platforms. I think the general direction right now is to unify desktops.

I think the goal certainly is to unify desktops but at the end of the
day different downstream consumers of e.g. HAL and GNOME have different
needs. Oh, and it should hardly be a surprise that I've been wanting the
user to auth to gain privs

 http://lists.freedesktop.org/archives/hal/2006-January/004377.html

It just so happened that I found out that state of the art in desktop
applications gaining privs isn't appropriate for the experience I want
gnome-mount to have. So I basically roll my own.

Btw, been doing some more thinking on how to do this:

 1. gnome-mount gets PermissionDeniedByPolicy for policy
    "storage-removable-mount" when doing Mount() on HAL

 2. gnome-mount connects to the org.freedesktop.PolicyKit service on the
    system message bus

 3. gnome-mount requests a new "session" with PolicyKit. Call this
    session S. A session has state, namely isAuthorized(), 
    setPolicy(), getPolicy() etc. etc.

 4. gnome-mount does S.setPolicy("storage-removable-mount")

 5. gnome-mount initiates auth conversation on S; this probably means
    that gnome-mount at some point will need to ask the desktop user
    for the root password or whatever (dependent on PAM). It might
    also be paper-rock-scissors, whatever :-)

 6. At the end of the conversation between gnome-mount and PolicyKit
    on the session S we know whether auth was successful. If it is
    unsuccessful the session S is torn down inside PolicyKit. If 
    successful, the PolicyKit daemon takes note of the pid and uid
    of the other endpoint of the session (e.g. gnome-mount). In
    particular it puts the (policy, uid, pid) tupple in a list
    called temporary_policy_overrides. Should the end-point suddenly
    disconnect we catch this and delete the tupple from the list
    temporary_policy_overrides.

 7. If successful, gnome-mount does Mount() again on HAL. This flows
    through HAL and eventually hal-storage-mount is invoked. This binary
    uses libpolkit in particular libpolkit_is_uid_allowed_for_policy()
    to check whether the given $HAL_METHOD_INVOKED_BY_UID and
    $HAL_METHOD_INVOKED_BY_PID (we will start exporting this soon in
    HAL :-) is privileged. 

    Today this is done by looking up in the configuration file but we
    will modify this method to ask the PolicyKit daemon in addition
    if the configuration file didn't allow us to do this (corollary:
    you don't need to run the PolicyKit daemon for something to succeed;
    it only grants you extra privileges). The PolicyKit daemon will look
    up in the temporary_policy_overrides list mentioned in step 6. and
    we will this time get TRUE. We mount and return to gnome-mount.

 8. HAL returns to gnome-mount and we now end the session S with the
    PolicyKit daemon. The PolicyKit daemon responds by removing the
    (policy, uid, pid) tupple from the temporary_policy_overrides
    list.

For implementing "allow authorized users to permanently grant this
privilege to self or other users" insert something trivial between
between 6. and 7. that includes GrantToUID() etc. calls on the session
object S on the PolicyKit daemon.

OK, so this is the high level stuff without too much hand waving I hope.
And I think it is secure. Comments?

Cheers,
David