Summary: | PAM messes up device permissions | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ernst Bachmann <e.bachmann> |
Component: | [OLD] Core system | Assignee: | PAM Gentoo Team (OBSOLETE) <pam-bugs+disabled> |
Status: | RESOLVED DUPLICATE | ||
Severity: | minor | CC: | avuton, gregkh, richard.adam |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | udev-048-ide-devfs_sh.patch |
Description
Ernst Bachmann
2004-12-07 06:28:12 UTC
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 *** |