the permissions defined by the /etc/security/console.perms file of pam are not consistent with the permissions defined by /etc/udev/permissions.d/50-udev.permissions. Esp. the permissions on audio devices seem to be screwed up. Let me give an example: User A is in the "audio" group, system has fresh booted, he ssh's in, and can play audio. Udev created the device nodes with root:audio:0660. This works as expected, after all User A is in the audio group for a reason. Now user B, who ISN'T in the audio group logs in on the console, and can play audio, too. Thats ok, he's in front of the machine after all. But pam has changed the permissions of the audio device nodes to B:audio:0600, so user A, who is still logged in, suddenly lost the right to play audio. Huh? Now if user B logs off, the situation still isn't fixed. The permissions get changed to root:audio:0600, so now root is the only one to use sound, the users from the audio group stay locked out. Obvious solution for user A: Walk over to the machine in question, and flipp the reset switch. Similar situation with CD Writers, but here the default udev config is at fault, too: they start as root:disk:0660 (users in "cdrw" can't burn cds :( ), get changed to <user>:disk:0660 (the user on console at least can burn now) they revert on logout to <root>:cdrw:0660 (yay! the cdrw group finally can use the cdrw drive!) next console login changes it to <user>:cdrw:0660. (Good! cdrw group still can use the burner!) For more examples, just compare the console.perms file with the udev permission file... Reproducible: Always Steps to Reproduce:
Mind making a patch for udev's permission file, as well as console.perms ? I have not the setup to test extensively currently, sorry.
Hmm, actually, cdrw's is quite a pita. Problem is how do you figure out which node are they with udev (cdrw is a symlink ...). Maybe should just use cdrom or disk ??
Created attachment 45929 [details, diff] udev-048-ide-devfs_sh.patch This should fix the group assigned by udev to be 'cdrw'.
As for the user that is logged in remotely ... the question is if he should retain rights if an user is logged in at the console ... I have a feeling the answer is no, as the user at the console prob want explicit access (he can actually hear what is playing, etc ...)
With udev-048, it have group 'cdrom' by default, and not 'disk'. I am wondering if it might not be easier to just drop 'cdrw' in favour of 'cdrom' ?
Well, about the audio permissions: Even without network login, those rules dont work as expected: kdm (I think gdm as well) offer a feature to start a new xsession on the same computer (e.g. when the scrensaver is running). Iow, they start a new X Server (:1, :2) on a new VT, and present a fresh login window there. while this is technically a new "console login", pam doesn't apply the permissions for it, as there is already one console user logged in. Again, the second user has no way to play audio, even if the first user has only a screensaver running, and he sits right in front of the speakers. Or, asking the other way round: What use is the audio group, when every user is able to superseed the restrictions set by root by simply logging in on the console?
As for the patch you asked for: I'd simply move /etc/security/console.perms to /etc/security/console.perms.sample and live without it. But that would require ppl to actually set up the group memberships of their users. But it then wouldn't change much for standalone workstations, and would probably reflect the sysadmins intentions on a networked setup better. the udev permissions file would require some changes, though: cdrw/cdrom groups, add iomega zip drives & similar to group "floppy" so that users with floppy access can format those medias, too, even if they come as harddisk device /dev/misc/rtc should be owned by group "video", so that mplayer can use it (if emerged with USE=rtc) joystick devices to group "games" or "users", modem/isdn devices to group "dialout" ? and so on... Quite a major change to the core system, nothing you should do without considering possible side effects carefully...
That is pretty much how pam_console behaves - it is intended for desktops where the user in front of the console should have permission to devices. We are planning on making it optional in future, and not enabled by default, but if that is what you want, you can disable it now.
Bug #31877 seems to be related...
*** Bug 80910 has been marked as a duplicate of this bug. ***
I think this one can be closed, one of the last updates changed /etc/pam.d/* to have "pam_console.so" commented out, so everything should be nice out-of-the-box now. I'd close it myself, but maybe the attached ide-devfs.sh patch is still needed?
Might still check with if it applies to latest udev if we still want cdrw's to be in the cdrw group ...
Considering it a dupe of 31877 as this regards pam_console. *** This bug has been marked as a duplicate of 31877 ***
