Re: handling group membership in and outside d-i
On Wed, Mar 04, 2009 at 06:12:54PM +0100, Josselin Mouette wrote:
> Le mercredi 04 mars 2009 à 17:55 +0100, Petter Reinholdtsen a écrit :
> > Personally, I believe adding users to these groups at install time is
> > the wrong approach, and believe the only scalable way to handle this
> > is with policykit like features. Then the group membership is handled
> > dynamically at login time, and every console user get the expected
> > privileges.
> ConsoleKit and PolicyKit cannot solve all use cases unless the whole
> stack is updated. This works very nicely for things like HAL: the device
> is handled purely by the process running as root, and the ability to
> talk to this process is controlled by the console access.
In what case do ConsoleKit and PolicyKit do this? My experience is that
they manage device permissions using acls, not using an intermediary root
process (which would be horrible for performance for things like audio in
particular).
> However, for e.g. audio access this cannot work unless all audio playback
> goes through a process running as a privileged user. With the current
> APIs, users need to be able to access the devices directly, and these are
> privileges you cannot revoke.
Yes, you still have the problem that there's no way at the kernel level to
force-close a file (/device) when permissions have been revoked. But using
acls on devices does at least reduce the scope of the problem from "find all
processes belonging to the user that still have this supplementary group
after the user's session has ended, and/or all setgid binaries they left
behind" to "find all processes belonging to the user that still have the
device open". The latter is sufficiently straightforward that you could
probably just use fuser and kill off any of the user's processes that still
have the device open when permissions have been revoked.
> Using things like pam_console or pam_group should not become our default
> policy, unless we at least ensure /home, /var and /tmp are mounted
> nosuid
I don't think there's any "unless" here - I think mounting /home nosuid is
the wrong default policy, and I think pam_groups is the wrong solution to
the groups problem for all the usual reasons.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: