[ConsoleKit] Permissions with consolekit and gdm

Brian Cameron brian.cameron at oracle.com
Fri Jul 2 10:24:15 PDT 2010


Kay:

>> What does consolekit do that causes the permissions to be changed if
>> gdm is used as display manager?
>
> It's probably udev which re-sets the permissions to the configured
> setting when something changes and a device event is handled.
>
> Changing primary ownership of device nodes to setting other than the
> ones specified in udev rules is not supported, udev will always
> restore the old setting with the next event for this device.

With all due respect, I believe that udev is a Linux specific interface.
I know that on OpenSolaris a legacy logindevperm(4) interface is used
to setup device permissions for users on login/logout.  logindevperm(4)
does not use a PAM module, so on OpenSolaris we have patched the
default login program, GDM, to parse /etc/logindevperm according to the
rules in the logindevperm(4) manpage.  However, this technique could
also be implemented in the GDM PreSession and PostSession scripts to
modify device permissions on user session login/logout.

The logindevperm(4) interface is straightforward, and the code is
available under a CDDL license.  It basically defines the format of
a flatfile database for managing device permissions.  To its credit it
is easily implementable by anyone via awk, sed, shell scripting, etc.
and the configuration file is easily human editable.  Though perhaps a
D-Bus interface for parsing the file might have value.

Here is some information about how logindevperm(4) works:

http://www.google.com/#hl=en&source=hp&q=logindevperm&aq=f&aqi=g2g-s2g1g-s1g1g-s2g1&aql=&oq=&gs_rfai=C-4tieBQuTIn_LaX4MbrIia4KAAAAqgQFT9DKTwc&fp=36ec6be010d257f

So, that is how device permission setup is different on OpenSolaris and
it seems to work well enough.  So, I hope that the ConsoleKit community
realizes that some ConsoleKit users do not have udev and that it works
pretty well without it currently.  I hope that does not change.  Device
management should be pluggable since distros should have the ability to
configure their systems and specify custom device management when
needed (e.g. mobile devices might have very different device management
needs than a laptop or terminal server).

How to handle changing device permissions (such as the audio device) on
VT switching seems to be a bit of an open question.  I would bet
support for this varies from distro to distro.  Whether or not its a
feature or a security concern to allow all VT sessions access to the
audio device at the same time is probably a question we will have until
something that allows sysadmins to configure how to handle situations
like this.

On OpenSolaris the default setting is to only allow the initial console
device access to devices, and if you switch to a VT session you lose
them (with exceptions for keyboard and mouse).  It is possible to
configure specific devices to have group or world permissions if
desired.  But it would be nice to manage this more nicely.  It would be
better if the audio system virtualized the device so multiple users
could connect to the sound system and have some central management and
configuration.  If PulseAudio supported this, then that would make
audio work much more nicely.  Also, how to handle removable media like
USB drives is I think the particular device management area that people
often complain about.  There are probably other devices to be concerned
about, but there are fairly easy to prioritize.  There are obviously
some devices that are more critical to support than others (e.g. ones
used by desktop interfaces).

If there were support for device management thatprovided this degree of
support as logindevperm(4) and which also resolved some of these sorts
of issues, then I think there would be interest in porting it to
OpenSolaris and retiring logindevperm(4).  At the very least, I hope
that discussing how this works on OpenSolaris adds some value to the
discussion.  There might be some good aspects of its design that are
worth thinking about.

Brian


More information about the ConsoleKit mailing list