>>On Fri, Feb 11, 2005 at 07:32:38PM -0800, Jeremy Utley wrote:
Actually, the "audio" group is exactly the wrong thing for this scenario; if I've got users who sometimes log in on the console and sometimes log in over SSH, I don't want them to have access to /dev/snd/dsp when they are coming in over a PTY. If they are in the "audio" group, they will have that access. Certainly it is more difficult to arrange this than just giving a bunch of users membership in the "audio" group in case they do decide to log in on the console, but if I choose to implement this I'll also have to _undo_ the "audio group" stuff that was put there by default.
Actually, the audio group is perfect for this type of scenario as well - see CONSOLE_GROUPS in /etc/login.defs. Just make sure the audio group is defined there, and users logged in at the console will be made part of the audio group, while users coming in remotely will not.
you care about that, I don't, but I would be interested in learning how to get fine grained permisions.
Then wouldn't it make more sense to simply have a 'console' group, so that the same membership can control use of all local resources, rather than having to add them into the audio group, the video group (so that locally logged on users can fire up X), the group that can use the USB scanner, etc...?
Granted you /could/ make the video card only accessible to the audio group, and you /can/ add a whole list of groups to the login.defs... Personally I use the single console group though (I also give console the ability to run halt and reboot - people here can hit the power button anyway, so might as well be able to do a clean shutdown).
~Ainsley
Younger siblings of mine tried just pushing the power button for their first few times on linux. I just told them to log off and leave the computer on, I would shut it down when I was ready. I never thought about configuring the system to allow only locally logged in users to shutdown the computer.
So my opinion on the devices, groups, and users is simply document what we do, why we do it, and put links to some resources explaining a way to do it different.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
