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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
