libhal-policy -> PolicyKit

[David Zeuthen]

On Wed, 2006-03-08 at 09:54 +0100, Ludwig Nussel wrote: 
> On Wednesday 08 March 2006 05:40, David Zeuthen wrote:
> > One thing that comes to mind is a tool that I want to call polkit-su
> > that enables e.g. desktop apps to easily become an otherwise
> > unprivileged user, polkit (user required for PolicyKit), that has wider
> > and less restricted access to D-BUS methods on e.g. HAL.
> > [...]
> > To do useful work obviously the program that is to be executed needs to
> > use D-BUS or similar and speak to a (system-wide) process with more
> > privileges. HAL, for instance.
> 
> I can't follow you with the idea of that additional unprivileged user. What
> exactly is a program running as that user supposed to do? If I understood you
> correctly you'd talk to that program [how?] so that it can talk to hal on your
> behalf. That looks like an unnecessary indirection to me.

It's a bit convoluted, but this is the idea. Assume we have a method
Format() on hal - the PolicyKit configuration for the privilege "format
a drive" is

 Allow=uid:0 uid:polkit
 Deny=

which means that only uid 0 and the polkit user can invoke it. Everyone
else get PermissionDeniedByPolicy. This is no big deal as the user
'polkit' is a system user and has the shell /sbin/nologin.

Now assume I'm logged in as uid 500 and gnome-format (doesn't exist yet)
invokes Format() - we get the PermissionDeniedByPolicy exception because
we are uid 500. Now gnome-format puts up a dialog asking for the root
password. Once that it obtained it invokes 'polkit-su -c
"gnome-format-su-helper -a <someArg> ..."' and writes the root password
on stdin or maybe on fd 3. We will have to define a sane protocol, since
it is likely we want to pass data to gnome-format-su-helper on stdin
too. This is all doable though it's probably hairy.

Now polkit-su checks the password (via PAM or /etc/shadow) and if it's
correct it becomes user 'polkit' and exec gnome-format-su-helper. The
gnome-format-su-helper now runs as uid 'polkit' and invokes Format() on
HAL. This succeeds because of the policy above.

Specifically all policy files will be owned by uid 'polkit' so
gnome-format-su-helper may change the policy to e.g. always allow uid
500 to do this in the future; e.g. the policy will be changed to

 Allow=uid:0 uid:polkit uid:500
 Deny=

The next time uid 500 tries this it will work without a password dialog.

Btw, the details of PermissionDeniedByPolicy even carries the name of
the policy, it could be one of storage-format-fixed-drives or
storage-format-removable-drives in case we want to make a distinction
between formatting fixed and removable drives. Which I guess we want
since it makes sense to allow Format() by default for removable media
but probably not for fixed drives. That's policy which is easily
tweakable by the OS vendor and/or the admin.

Specifically for gnome-mount I just plan to reexec gnome-mount as uid
'polkit' and make gnome-mount take the mount options and mount point on
the command line along with --text and --no-ui (to not use UI dialogs).
It does complicate the codepaths a bit but for this kind of stuff you
normally want it work from the commandline too.

Ideally we'd just use su(1) for this but su(1) can't read the password
from stdin :-/

Hope this clarifies.

Cheers,
David