replace PolicyKit with resmgr

Ludwig Nussel ludwig.nussel at suse.de
Mon Jun 26 06:01:56 PDT 2006


Hi,

I noticed polkit got a pam module that only serves the purpose of
automatically granting the desktop-console privilege via polkitd.
Isn't that exactly the same as with pam_console causing "at_console"
to be set? The new pam module looks redundant to me.

If you need something that tracks logins via pam there is an
existing, more flexible solution: resmgr[1]. The conditions for
certain privileges are not hardcoded in the pam module but are
configurable via a text file instead. Since we have no pam_console
on SUSE Linux the desktop class is used by dbus for the "at_console"
feature already. By default access to the desktop class is granted
when you log in via X or on a text console:
$ tail -1 /etc/resmgr.conf.d/99-desktop.conf 
allow desktop          tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:*

You can also match pam service, user name, remote host etc instead
of tty.

Since resmgr classes are just strings they can be viewed as polkit
privileges. To demonstrate that I wrote small replacements for
libpolkit and libpolkit-grant that talk to resmgr instead of
polkitd: http://www.suse.de/~lnussel/libpolkit-resmgr

This is how it looks:

$ polkit-list-privileges 
privilege audioplayer (temporary)
privilege pda (temporary)
privilege scanner (temporary)
privilege camera (temporary)
privilege usb (temporary)
privilege floppy (temporary)
resource /dev/fd0 privilege floppy (temporary)
privilege cdrom (temporary)
resource /dev/hdc privilege cdrom (temporary)
resource /dev/hdd privilege cdrom (temporary)
privilege input (temporary)
resource /dev/input/event0 privilege input (temporary)
privilege video (temporary)
privilege sound (temporary)
resource /dev/snd/timer privilege sound (temporary)
resource /dev/snd/seq privilege sound (temporary)
resource /dev/snd/pcmC0D1p privilege sound (temporary)
resource /dev/snd/pcmC0D1c privilege sound (temporary)
resource /dev/snd/pcmC0D0p privilege sound (temporary)
resource /dev/snd/pcmC0D0c privilege sound (temporary)
resource /dev/snd/controlC0 privilege sound (temporary)
resource /dev/mixer privilege sound (temporary)
resource /dev/adsp privilege sound (temporary)
resource /dev/dsp privilege sound (temporary)
resource /dev/audio privilege sound (temporary)
resource /dev/mixer1 privilege sound (temporary)
privilege v4l (temporary)
privilege dvb (temporary)
privilege desktop (temporary)
resource /dev/console privilege desktop (temporary)

'temporary', 'restrictions' and any dbus connection related stuff is
not handled by resmgr but I doubt those features are actually needed
anyways. We don't need to 'protect' two processes with the same uid
from each other and all privileges are revoked when the user logs
out anyways. I don't understand what 'resources' are supposed to be
so I just used them for the devices that are associated with
classes.

Devices are what resmgr primarily manages. If you get access to a
class, resmgr installs file system ACLs on the devices that are
associated with the class. By using ACLs it's possible to have
multiple concurrent logins of different users at the same time and
each one gets access to the devices. resmgr falls back to chown if
the fs doesn't support ACLs. So it behaves like pam_console (resp
pam_devperm) then.

Back to polkit. resmgr itself has no means for a user to acquire
additional privileges like that pam-via-dbus interface of polkit.
I don't think such a complex construct is needed though. Running
"gnomesu resmgr grant $USER $PRIVILEGE" is equivalent and can be
used by non-dbus applications as well.

So what about using the already working resmgr as replacement for
polkit (and pam_console)?

For the future I am thinking about getting rid of the resmgr daemon
by having the library store all state entirely in the fs instead of
talking to a daemon. The library interface would still be
compatible.

cu
Ludwig

[1] http://forgeftp.novell.com/resmgr/web/

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/



More information about the hal mailing list