. Reproducible: Always Steps to Reproduce: 1. login in on on a virtual terminal as normal user 2. check permissions on pam_console managed devices for example: ls -l /dev/floppy/0 3. press <Ctrl><Alt><Del> 4. wait for comp to reboot 5. login on on any virtual terminal as root 6. repeat step 2 Actual Results: /dev/floppy/0 is still owned by the last logged in user! same problem with serial ports! same problem with cdroms/zips/usb-storage devices/... same prob with all devices managed by pam_console!!! Expected Results: devices should have ownership from devfsd.conf or root:root! possibly related: bug #26648 bug #26648
sorry, typo second related bug is #28407
Hm, I was always under the impression pam and devfs are things that are meant to be configured after install... The problem is you're saving device permissions to `/lib/dev-state' and have devices managed by `pam_console' at the same time...some admins may prefer `dev-state', others may want to use pam_console... Me, I don't use either. Which configuration is better really depends on how a particular machine is used. What happens in this case is, when a user logs in, `pam_console' changes permissions/ownerships of the devices it manages, which devfsd immediately saves to `/lib/dev-state'. On reboot or shutdown, `pam_console's session_close hook doesn't undo that... maybe because devfsd is already dead when the user's login-shell is killed (changes are reversed but not copied to dev-state), maybe because the login process that is wait()'ing on the login-shell dies before the login-shell itself (means pam_close_session is not called). On next reboot, when devfsd starts up, plus whenever a device is registered, the following lines in `devfsd.conf' RESTORE /lib/dev-state REGISTER .* COPY /lib/dev-state/$devname $devpath #(1) copy device nodes from `/lib/dev-state' back to `/dev' (<-here's the root of the problem) The `pam_console_apply_devfs.so' line a few lines down in devfsd.conf (commented out by default) would set permissions according to `console.perms', but it can't be used with (1) above because they're both triggered by the same event. Only way I see to avoid this kind of situation is to disable either dev-state, pam_console, or both.
Ok Seeing that you already solved two of my other problems and that one of your kernel patches made it into stable in no time, I believe you; although I'm not sure I follow what you just said :-) I'm pretty sure I've seen a similar setup in Mandrake. Also, the Installation Guide doesn't say anything about that PAM files or devfsd.conf should be modified. The Device File System Guide specifically says, and I quote, "Although you can set permissions in /etc/devfsd.conf, you are advised to use PAM (Pluggable Authentification Modules). This is because PAM has the final say on permissions, possibly ignoring the changes you make in /etc/devfsd.conf." /lib/dev-state is also mentioned, but only how it works; not that and how you disable it. I'm confused.
You will see devfsd is only stopped in /etc/init.d/halt.sh, which is much later (and after the killall5 from init), thus it will rather be a bug with the `pam_console_apply_devfs.so' module not resetting permissions ...
Could you both please try to keep it a bit less technical? I'm sure both comments are helpful; I just don't know how. Like I already said, devfsd.conf on a Mandrake machine looks almost the same. When I boot in a different partition and check Mandrake's /lib/dev-state, it still has the old permissions; many devices belong to the user who was logged in at <Ctrl><Alt><Del>. But when I boot back into Mandrake and log in remotely or as root, everything is like it should. I'm still confused about `pam_console_apply_devfs.so'. In Gentoo its commented out; Mandrake doesn't have this line; if I uncomment it in Gentoo nothing changes???
No, like mentioned above...if you save to `dev-state', you need `pam_console_apply*', but you can't use `pam_console_apply_devfs.so' if you restore from `dev-state'. It's a deadlock situation. Some background (as "untechnical" as possible) : `pam_console' is a module that provides session support, that is, whenever a user logs in successfully, pam-aware applications that have `pam_console' listed as a session module will call the module's `open_session' hook. If the same user logs out, the module's `close_session' hook is called. open_session(), among other things, first makes sure that no other local user exists, then creates a lock file for that user and changes permissions of matching devices according to the second column in `console.perms' and transfers ownership to that user. close_session() removes the lockfile and sets perms/ownership according to the 4th/5th column in `console.perms'. pam_console also comes with two additional modules... `pam_console_apply' is a standalone program. If called without arguments, it does the same as `open_session()' if there is a lock- file in `/var/run/console', and the same as `close_session()' if there is no such lock. `pam_console_apply_devfs.so' is a shared library that basically provides the same functionality again, except it is intended to be used from within `devfsd.conf', and acts on a single device node at a time. To get a clean state after boot on a non-devfs setup, you would call `pam_console_apply' early in the boot process, this sets permissions on devices pam_console handles to the values in `console.perms'. On devfs setups, `devfsd.conf' should contain this line REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so\ pam_console_apply_single $devpath #(2) which does the same as above at device registration time, i.e., at the time a device is created as a result of a loaded module, *even if a user holding the lock is already logged in*. (note that when devfsd (re)starts it generates synthetic register events for already existing nodes). If you also have `dev-state' enabled, you also have REGISTER .* COPY /lib/dev-state/$devname $devpath Since these two lines fire at the same event on the same devices, only one can win. Since the order is the reverse of the config file, `dev-state' will override `pam_console_apply_devfs's actions. [the latest set of Mandrake CDs I have here is 7.something (vitamin), could someone reading this with a more recent version verify if the following is still true?] Mandrake, although it uses devfs, copies the whole `/lib/dev-state' over to `/dev' after mounting `/dev', but before starting devfsd, then runs `pam_console_apply -r'. This solves the problem of stale permissions, but not the case when a module is loaded *after* a user logs in (for instance, the user's desktop env plays its startup sound => sound module is autoloaded => perms are from devfsd.conf. User logs out and back in => module is already loaded => perms will be from console.perms). [I must admit, I don't read docs, and I didn't even know there is a Devfs Guide. Checking it later tonight, including the context the quote above is given]
*knock* *knock* so to summarize, If I want to use pam_console, I need pam_console_apply_devfs, right? But if I want to save device files in /lib/dev-state, I can't use pam_console_apply_devfs, right? I'm still sure Mandrake 8.2 uses such a setup, but as it seems theirs works 9 out of 10 times; maybe they just time their stuff differently? Doc-people, adding you to CC; if there's no clean solution I think there should be a chapter in the Device file System Guide on howto disable pam_console and|or /lib/dev-state.
Bah; using documentation to provide information on ugly situations isn't really fun and isn't usefull to the users too. In fact, they are more scared of such situations. Can't we have a correct REGISTER line in devfsd.conf that uses one way (either lib-state, or console.perms) and shut up about it (as it then works one way)?
NO! To not warn users about serious problems is even worse. I've talked to a few people since I've discovered this problem and they all say that pam_console AND dev-state, are quarter-assed red hat inventions aimed at newbies and should NEVER BE USED in semi-production enviornments. pam_console is totally useless; device permissions are already granted by group memberships, unfortunately pam_console changes audio devices to 0600 user.audio and then back to 0600 root.audio; no point having an audio group; audio members will not be able to use audio! Still, pam-0.77 still gives full rw-access to serial ports, a feature not even in the original red hat sources, and /dev/console; huge security risks! Until these issues are solved I say it should be documented how to disable this mess. Unfortunately pam_console references are everywhere in various places that I didn't even managed to get rid of the problem described at the top of this page without breaking something else.
I'm a bit confused now. What is the proposed solution then? If I understand it, the current situation is broken (two implementations that do the same, but differently and are interfering). So to fix it, one of them should be chosen, right? Why use documentation (knowing that only a small part of the users will read it) if we can just "update" the relevant files (i.e. ebuilds)?
pam_console has never been anything but a pain in the rear that has to be worked around because it frequently leaves device ownership in an undesirable state (sound and nvidia* devices owned by root or another user who has long since logged out, etc.) Can we work towards eliminating pam_console altogether, or at least add a USE flag so that those who have to use it can enable support for it, and the rest of us can manage device permissions with the normal access control facilities?
I agree. security and consistency should be higher priority than newbiefriendlieness.
Is the issue still relevant for baselayout-1.8.6.12-r2 ? It reverts the permissions done via pam_console (totolly different issue it was added, but oh well).
yup, no difference with baselayout-1.8.6.12-r2 at all I still don't get whats so special about pam_console; even though RH seems to maintain pam, its not in the official pam tree; and everybody else besides rh and mdk try to avoid it like hell (rh apparently doesn't even use it in its own server products). I asked this before and I ask it again: if users already have access from their group membership, WHY CHANGE OWNERSHIP???
Still no resolution on this bug... I suggest somebody(ie end users) start attaching updated ebuilds & diffs/patches that have been tested and proved not to cause problems when pam_console is not used.
any progress on this?
pulling aron in on cc so that he can have some input on the fix0rs
So where Gentoo developers are heading? the choice is well-defined: - default permissions based on group membership. - default permissions based on console ownership. In either case, the patches are quite trivial to implement (a lot more difficult is to make users migrate smoothly). In the first case, we need to patch the 8 ebuilds that provide pam_console in their default pam.d file (including shadow, kdebase, gdm), and leave the default devfsd.conf without pam_console_apply_devfs. This can imply a lot of complaints from users that can no more hear sounds, or burn CDs, because they are not in the right group. And we need more explicit documentation, naturally. In the second case, we need to deactivate dev-state and activate pam_console_apply_devfs in default devfsd.conf, and to change the documentation to reflect this fact (no more need to be in the audio group, etc.). What do you propose?
Gregorio: ``So where Gentoo developers are heading? the choice is well-defined: - default permissions based on group membership. - default permissions based on console ownership.'' I would say the former. I'm afraid I'm not at all familiar with pam_console, but it doesn't seem that it's absence would be a terrible problem. Basically, as you said, it may result in users having no access to devices. Fine. After all, if a user wants access to play sounds, put him in the ``audio'' group. If a user needs to be able to mount disks, do the same. This is a situation where we should do what *I* see as being the ``good Gentoo thing''; that is, Keep It Simple, do what is most consistent and least feature-bloated, and let users add to it as they wish. Pam_console doesn't seem to be necessary *by default*. Incidentally, as I said, I truly am not familiar with pam_console. Don't take any of the above as gospel. If I've made a speak-o, say so.
*** Bug 53377 has been marked as a duplicate of this bug. ***
I'd opt for. - default permissions based on group membership.
Thanks for the feedback, if you assure me that this opinion (default permissions based on group membership) is common amongst developers, we could start sending patches. Just say so...
*** Bug 61518 has been marked as a duplicate of this bug. ***
Gregario: I confer with solar that permissions based on group membership is best. If we redo group membership properly, also see bug #28407, comment 31, and I then don't see any need to keep pam_console.
Ok, so here's a tentative implementation plan: step 1) push out a new revision of sys-libs/pam, providing a file README.pam_console in /usr/share/doc explaining that permissions based on group membership are default and how to enable pam_console (will attach in a minute). step 2) push out a new revision of sys-apps/shadow that provides an /etc/pam.d/system-auth with these (commented) lines # if you want to enable pam_console, uncomment the following line # and read carefully /usr/share/doc/<whatever>/README.pam_console #session optional /lib/security/pam_console.so Still no visible changes for the user, though, pam_console is still enabled in other pam.d files. step 3) review the documentation, in particular the handbook section 11.a being more explicit about the groups a user can belong to and the effects. Maybe insert a table with the possibilities: wheel -> be able to change to root using su audio -> be able to access audio devices video -> be able to access video capturing hardware and doing hardware acceleration games -> be able to play games usb -> be able to access usb devices cdrom -> be able to access cdrom devices floppy -> be able to access floppy devices ...something else? maybe 'dialout' for bug 28407 step 4) Patch the following ebuilds: app-admin/conserver app-admin/usermin gnome-base/gdm kde-base/kdebase net-www/mod_auth_external net-www/mod_auth_pam sys-apps/shadow x11-base/xfree x11-base/xorg x11-misc/wdm and in particular these files: app-admin/conserver/files/conserver.pam app-admin/usermin/files/usermin.pam gnome-base/gdm/files/2.4.1/pam.d/gdm gnome-base/gdm/files/2.4.4/pam.d/gdm-autologin gnome-base/gdm/files/2.4.4/pam.d/gdm gnome-base/gdm/files/2.2.5/pam.d/gdm gnome-base/gdm/files/2.6.0/pam.d/gdm-autologin gnome-base/gdm/files/2.6.0/pam.d/gdm kde-base/kdebase/files/kde-np.pam kde-base/kdebase/files/kde.pam net-www/mod_auth_external/files/pwauth.pam net-www/mod_auth_pam/files/apache2.pam sys-apps/shadow/files/pam.d/login x11-base/xfree/files/4.3.0/xdm.pamd x11-misc/wdm/files/wdm xdm.pamd (from distfiles/xorg-x11-*-files.tar.bz2) (please check if something is missing) removing all instances of pam_console.so, and maybe adding an einfo about the change. Something like * Since version xxx package yyy does not use pam_console by default anymore. * Make sure the users on the system belong to the right groups as specified * in the gentoo handbook (<link>), otherwise you could experience problems * accessing devices. * See /usr/share/doc/<...>/README.pam_console for further details. step 5) Make sure the permissions in the default udev.permissions and in the default devfsd.conf as provided by baselayout (why is it not provided by devfs BTW?) are consistent with the table in the handbook. devfsd.conf will need a bit of work. step 6) Push the packages in step 4 to stable, and deal with tons of incoming bugs. What do you think?
Created attachment 39249 [details] proposed README.pam_console
No problem on the documentation part. I believe this is already affective so I can start with adding this information in, no? Or should I wait until steps 1 & 2 are done?
Any feedback on this?
I think the documentation should be a little more specific about how the groups system works. And state more explicilty the merits of the diffrent sollutions. I.e. pam_console makes it impossible(?) to have more than one user at time. I think users could think that the steps outlined are part of the normal installtion.
This type or cross-responsability bugs do not fly very well... Let's try to apply the plan outlined in comment #25, since nobody objected... Sven: the doc team should probably work on step 3 right now. pam-bugs: comment/implement step 1 please base-system: comment/implement step 2 please Once this is done we'll track individual package maintainers to get step 4 done.
pam maintains pam ... updated metadata to reflect this
vapier: I pulled base-system in because you still maintain shadow... which is what step 2 is about. Unless you also update shadow's metadata.xml ?
Isn't "tty" also a rather important group?
Sven, take a look at bug 28407 (it's funny reading anyway), in particular comment 22. I didn't know what to do after reading that.
Wonderful; the tty was added due to Bug #53086, now I have one stating (well, does it or not? not sure) that it should be removed.
Oh, and I forgot 2 things: add to step 5: Make sure that the MAKEDEV script (from baselayout) is consistent with the table in the handbook (the first part is meant to be customized), for those with static /dev. add step 4.5) probably the lines that call "pam_console_apply -r" should be removed from init.d/bootmisc and init.d/halt.sh (from baselayout).
The installation instructions are updated with the requested groups information.
Thanks Sven... so now we better hurry up a bit on step 5, to avoid having things lingering in an inconsistent state for a long time. I took a look at udev.permission, and I think it's good as it is now, it respects the table in the handbook. Only concerns could be that printers and scanners are left alone without a corresponding group. If anyone has some experience with printers and scanner devices, he can say if it is worth doing something. default devfsd.conf needs some patching. At least something like this is needed for cdroms: -# Give the cdrw group write permissions to /dev/sg0 +# Give the cdrom group write permissions to /dev/sg0 # This is done to have non root user use the burner (scan the scsi bus) -#REGISTER ^scsi/host.*/bus.*/target.*/lun.*/generic PERMISSIONS root.cdrw 660 +REGISTER ^scsi/host.*/bus.*/target.*/lun.*/generic PERMISSIONS root.cdrom 660 + +# Give the cdrom group access to the cdrom devices +REGISTER ^scsi/host.*/bus.*/target.*/lun.*/cd PERMISSIONS root.cdrom 660 +REGISTER ^ide/host.*/bus.*/target.*/lun.*/cd PERMISSIONS root.cdrom 660 but I don't have devfs and I can't test it, and I have absolutely no idea on how to write rules for usb and floppy, which are currently missing. If someone with devfs could try... /sbin/MAKEDEV is not entirely correct, but I think it will not cause troubles if we just ignore it. Thinking more about the table, I would change: cdrom: be able to access cdrom devices with cdrom: be able to directly access cdrom devices (e.g. to listen or rip audio CDs, or to burn CDs) and floppy: be able to access floppy devices with floppy: be able to directly access floppy devices (e.g. to format discs) to avoid confusion: data on cdroms and floppies can be accessed by a user if he can mount the device, and that is decided by the 'user' option in /etc/fstab, not by group membership (is it worth explaining that better in the handbook?) Last thing: I see the handbook still has the 'tty' group in the example command in code listing 1. Since everything works fine here without being in the tty group, I vote for removing it.
OK so now we need base-system to help with step 2 (shadow) and step 5 (devfsd). pam_bugs should help with step 1 (pam). Raising severity since docs are in advance...
Switching to Default Configs and *bump*
*** Bug 73215 has been marked as a duplicate of this bug. ***
Creating sub-bugs to handle this meta-issue more clearly. The plan we follow is the one at comment #25 which nobody complained about. Using this bug as a tracker.
*** Bug 56753 has been marked as a duplicate of this bug. ***
bug #72199 is related to this problem - pam_console_apply being run on boot by /etc/init.d/bootmisc.
So when does this get fixed?
When all steps are done and all dependant bugs are fixed. See comment #25.
Ack, typo. Should have been: bug #72119
bug #70990 appears to be related to this one.
bug #42139 appears to be related to this one.
Bug #73660 seems to be related
Step 2 and 3 are done... still waiting on step 1 (bug 73677) though.
Whee, this is fun. bug #55305 also appears to be associated with this bug, as well as bug #66268, which, according to that reporter, pulls in these bugs: Bug #1658 Bug #27857 Bug #29463 Bug #46524 Bug #59085 Bug #73660 I think when this is done you'll have closed like 5% of the bug database. :)
bug #77093 is tangentially related to this one in that he's talking about separate ebuilds for pam modules.
bug #76887 also appears to be related.
bug #69476 also looks to be the work of pam_console.
Found a couple more to track down after this is fixed: bug #55585 bug #56671
Looks like all first 3 steps have been completed... Gregorio: could you check that we are ready for step 4/5 ? Here is the rest of the plan : ======================================================= step 4) Patch the following ebuilds (and put them in ~): app-admin/conserver app-admin/usermin gnome-base/gdm kde-base/kdebase net-www/mod_auth_external net-www/mod_auth_pam sys-apps/shadow x11-base/xfree x11-base/xorg x11-misc/wdm and in particular these files: app-admin/conserver/files/conserver.pam app-admin/usermin/files/usermin.pam gnome-base/gdm/files/2.4.1/pam.d/gdm gnome-base/gdm/files/2.4.4/pam.d/gdm-autologin gnome-base/gdm/files/2.4.4/pam.d/gdm gnome-base/gdm/files/2.2.5/pam.d/gdm gnome-base/gdm/files/2.6.0/pam.d/gdm-autologin gnome-base/gdm/files/2.6.0/pam.d/gdm kde-base/kdebase/files/kde-np.pam kde-base/kdebase/files/kde.pam net-www/mod_auth_external/files/pwauth.pam net-www/mod_auth_pam/files/apache2.pam sys-apps/shadow/files/pam.d/login x11-base/xfree/files/4.3.0/xdm.pamd x11-misc/wdm/files/wdm xdm.pamd (from distfiles/xorg-x11-*-files.tar.bz2) (please check if something is missing) removing all instances of pam_console.so, and maybe adding an einfo about the change. Something like * Since version xxx package yyy does not use pam_console by default anymore. * Make sure the users on the system belong to the right groups as specified * in the gentoo handbook (<link>), otherwise you could experience problems * accessing devices. * See /usr/share/doc/<...>/README.pam_console for further details. step 5) Make sure the permissions in the default udev.permissions and in the default devfsd.conf as provided by baselayout (why is it not provided by devfs BTW?) are consistent with the table in the handbook. devfsd.conf will need a bit of work. ======================================================== Maybe the list should be updated with the current portage ?
pls dont forget steps from comment #36(especially 4.5, as this is really annoying at the moment) ----------------------------------- add to step 5: Make sure that the MAKEDEV script (from baselayout) is consistent with the table in the handbook (the first part is meant to be customized), for those with static /dev. add step 4.5) probably the lines that call "pam_console_apply -r" should be removed from init.d/bootmisc and init.d/halt.sh (from baselayout). ---------------------------------------------------------- as for step 5) i think Gregorio more or less dealed with it: see comment #38 here and bug #80360 as for step 4.5) im not sure if is possible to determine if pam_console is enabled in the initscript(beside grep'ing for it in /etc/pam.d/* ) see comments #8, #9,#12 in bug #73677. So maybe move that to an extra initscript which the user has enable when he want to use pam_console?
forget to mention that in my previous post: Maybe the Gentoo Devfs Guide(http://www.gentoo.org/doc/en/devfs-guide.xml) should also be updated reflecting this change.atm it is reading like this: =========================================================== 4. Permission Related Items Set/change permissions using PAM Although you can set permissions in /etc/devfsd.conf, you are advised to use PAM (Pluggable Authentification Modules). This is because PAM has the final say on permissions, possibly ignoring the changes you make in /etc/devfsd.conf. PAM uses the /etc/security/console.perms file for the permissions. The file consists of two parts: the first one describes the groups, and the second one the permissions. [...] ================================================================== should be changed to advise that you can change permissions in /etc/devfsd.conf(unless you enabled pam_console)
> add step 4.5) probably the lines that call "pam_console_apply -r" > should be removed from init.d/bootmisc and init.d/halt.sh (from baselayout). Then you shoot those using it in the foot. The checks should rather be improved to check _if_ you use pam_console or not as well.
So, let's summarize what's left to do: 1) figure out a solution for "pam_console_apply -r" in /etc/init.d/bootmisc and /etc/init.d/halt.sh If I understood correctly, running "pam_console_apply -r" there is needed to make sure that the device tarball created in /lib/udev-state when using udev, does not have entries with improper permissions; and to make sure that even if it has improper permissions, that those permission are resetted at boot. But those commands should not run if pam-console is not enabled (see bug 72119). 2) A setup without pam-console works best in this setting: a recent reinstall of sys-apps/shadow >=sys-libs/pam-0.77-r8 a recent reinstall of sys-fs/devfsd (for proper permissions) >=sys-fs/udev-052 (not strictly necessary) so probably we should wait some time for these packages to stabilize. 3) open new bugs for the ebuilds listed in the plan, requesting the removal of pam_console.so from their pam.d files.
Added this to baselayout: ----- Index: init.d/halt.sh =================================================================== RCS file: /var/cvsroot/gentoo-src/rc-scripts/init.d/halt.sh,v retrieving revision 1.71 diff -u -r1.71 halt.sh --- init.d/halt.sh 25 Feb 2005 18:51:20 -0000 1.71 +++ init.d/halt.sh 25 Feb 2005 20:47:08 -0000 @@ -8,8 +8,9 @@ source /sbin/livecd-functions.sh && \ livecd_read_commandline -# Reset pam_console permissions -if [ -x /sbin/pam_console_apply ] && [ ! -c /dev/.devfsd ] +# Reset pam_console permissions if we are actually using it +if [[ -x /sbin/pam_console_apply && ! -c /dev/.devfsd && \ + -n $(grep -v -e '^[[:space:]]*#' /etc/pam.d/* | grep 'pam_console') ]] then /sbin/pam_console_apply -r fi Index: init.d/bootmisc =================================================================== RCS file: /var/cvsroot/gentoo-src/rc-scripts/init.d/bootmisc,v retrieving revision 1.47 diff -u -r1.47 bootmisc --- init.d/bootmisc 30 Jan 2005 21:20:24 -0000 1.47 +++ init.d/bootmisc 25 Feb 2005 20:47:08 -0000 @@ -61,8 +61,9 @@ fi done fi - # Reset pam_console permissions - if [[ -x /sbin/pam_console_apply ]] && [[ ! -c /dev/.devfsd ]] ; then + # Reset pam_console permissions if we are actually using it + if [[ -x /sbin/pam_console_apply && ! -c /dev/.devfsd && \ + -n $(grep -v -e '^[[:space:]]*#' /etc/pam.d/* | grep 'pam_console') ]] ; then /sbin/pam_console_apply -r fi # Create the .keep to stop portage from removing /var/lock
Hi all, as I'm running an "unstable", udev-only system with recent versions of pam, shadow, baselayout, pam-login, ... I just wanted to report what I'm experiencing on my system concerning this issue: I have problems using my burner/cdrom - the rest works just fine. I have pam-0.78 pam-login-3.17 udev-054 baselayout-1.11.9-r1 shadow-4.0.7-r1 My normal user is in groups: disk lp wheel audio cdrom video portage users The permissions are as follows: --------------------------- > ls /dev/sound/ total 0 drwxr-xr-x 2 root root 160 Feb 26 10:58 . drwxrwxrwt 21 root root 14K Feb 26 11:01 .. crw-rw---- 1 root audio 14, 12 Feb 26 10:58 adsp crw-rw---- 1 root audio 14, 4 Feb 26 10:58 audio crw-rw---- 1 root audio 14, 3 Feb 26 10:58 dsp crw-rw---- 1 root audio 14, 0 Feb 26 10:58 mixer crw-rw---- 1 root audio 14, 1 Feb 26 10:58 sequencer crw-rw---- 1 root audio 14, 8 Feb 26 10:58 sequencer2 --------------------------- Seems to be correct. --------------------------- > ls /dev/hd* brw-rw---- 1 root disk 3, 0 Feb 26 2005 /dev/hda brw-rw---- 1 root root 3, 1 Feb 26 2005 /dev/hda1 brw-rw---- 1 root root 3, 2 Feb 26 2005 /dev/hda2 brw-rw---- 1 root root 3, 3 Feb 26 2005 /dev/hda3 brw-rw---- 1 root root 3, 4 Feb 26 2005 /dev/hda4 brw-rw---- 1 root root 3, 5 Feb 26 2005 /dev/hda5 brw-rw---- 1 root root 3, 6 Feb 26 2005 /dev/hda6 brw-rw---- 1 root root 3, 7 Feb 26 2005 /dev/hda7 brw-rw---- 1 root root 3, 8 Feb 26 2005 /dev/hda8 brw-rw---- 1 root disk 3, 64 Feb 26 2005 /dev/hdb brw-rw---- 1 root root 3, 65 Feb 26 2005 /dev/hdb1 brw-rw---- 1 root root 22, 0 Feb 26 2005 /dev/hdc brw-rw---- 1 root root 22, 64 Feb 26 2005 /dev/hdd --------------------------- Why are there some devices with different permissions? /dev/hdc and /dev/hdd are the problem (cdrom and burner) because they don't belong to group "disk". How and where can I fix this (correctly) by sticking to the "permissions based on group membership" solution? I remove my normal user account from group tty according to a comment in one of the many related bugs (sorry, I forgot which one). The permissions on /dev/tty are: --------------------------- ls /dev/tty crw-rw-rw- 1 root tty 5, 0 Feb 26 11:00 /dev/tty --------------------------- Thats not correct according to the same comment/related bug. How to fix this?
My cdrw is in the cdrom group. Please attach your /etc/udev/rules.d/50-udev.rules.
I'm using the standard 50-udev.rules from udev-054 without any modifications.
All the permission/group info also moved to it with 0.50 or something - just wanted to make sure you did merge the changes ...
I'd like to comment on this bug : I manage an X terminal server for 4 other terminals. Since all terms are in the same room, I put speakers on the server so that people could listen to music or have sounds for their apps. The problem is that this bug made my life very difficult as I had to reset sound perms every hour or so (even made it a crontab). My solution to this problem was to empty (not remove though) the console.perms file altogether. However the default udev permission file at that point was too poor (045 or something). I had to modify half a dozen rules to accomodate our needs. A few days ago, udev-056 was made stable and as I merged it, I saw that all the things I manually edited were fixed, and much more. As gentoo's udev stands today, it completely obsoletes console.perms (from my point of view ... but check the forums, I'm not alone :) Audio devices always belong to the audio group, optical drives all end up in the cdrom group, and nvidia/ati/fb devices to the video group. I've made this small modification to several boxes (about a dozen including ia64) and the results were always as expected. I think this would make every one's life easier (including the support forums) as it would be one less thing to worry about.
may i ask whats the status on this issue? as far as i have seen the patch from comment #62 hasnt been arrived in a baselayout release.
AFACIT we were following the remaining items on comment #61. azarah/greg_g, are we ready to hunt down pam_console consumers and beat them to death ? Or do you still think we need to let the other things propagate ?
I'm hunting pam_console-using packages as much as pam_stack-using packages to make them work on g/fbsd. The pamd files should just use optionally pam_console if present, in this way if the user hasn't pam_console at all the problem should be ok, shouldn't it? pam_console useflag is disabled by default so it's not build by default in newer versions of pam. (sorry if I said something wrong, but too much history to read in this bug and i just jumped here and there trying to understand the issue afaic.)
(In reply to comment #70) > The pamd files should just use optionally pam_console if present, in this way if the user hasn't pam_console at all the problem should be ok, shouldn't it? > pam_console useflag is disabled by default so it's not build by default in newer versions of pam. Basically, after pam_console is removed from the pam.d files, it becomes a setting adjustable at global level, so packages should not bother with it anymore and this shouldn't be an issue. About this bug, I think having a stable release of baselayout-1.11.x is quite important before proceeding, maybe azarah can give a timeline on that?
Ok, we can go on with this now. But first we need an opinion from azarah and flameeyes, since they changed the pam setup quite a lot in the meantime: According to the original plan, at the end the pam_console setting would be present only in /etc/pam.d/system-auth, commented by default, so that uncommenting it would enable pam_console globally. I see the commented pam_console line was moved from /etc/pam.d/system-auth to /etc/pam.d/login (so that it only affects console logins now), it should be moved back if we respect the original plan. Also, you introduced the pam_console USE flag in sys-libs/pam, did you intend use it to decide whether pam_console is to be enabled globally or not on the system? If this is the case, this would conflict with the plan. Or it's only meant to enable the compilation of the pam_console module, without bothering whether it would enable pam_console globally or not?
I do not see why pam_console should be global .. you only want it at login or maybe for xdm/gdm/whatever. As for the USE flag ... its only to get it compiled. I think current status of kernel 2.6 and udev really only makes pam_console valid for extreme cases, and are really thinking about just removing it in total, and if somebody is bothered enough, just add an seperate ebuild. As for the devfs support in 0.78 ... I make it compile, but I am not even sure if that works properly any longer, so I will definately drop that when I eventually get to 0.79.
(In reply to comment #73) > I do not see why pam_console should be global .. you only want it at login or > maybe for xdm/gdm/whatever. What should be the preferred method for a user to enable or disable it for both login and *dm then? If you decide to keep the commented pam_console line out of /etc/pam.d/system-auth, please specify in README.pam_console that enabling it in /etc/pam.d/login is not enough, as most users use graphical logins. BTW, I fully agree with separating pam_console in a different ebuild. This would make the pam_console flag disappear, right?
(In reply to comment #74) > (In reply to comment #73) > > I do not see why pam_console should be global .. you only want it at login > or > > maybe for xdm/gdm/whatever. > > What should be the preferred method for a user to enable or disable it for > both login and *dm then? > If you decide to keep the commented pam_console line out > of /etc/pam.d/system-auth, please specify in README.pam_console that > enabling it in /etc/pam.d/login is not enough, as most users use graphical > logins. > Yeah, should be added to login/xdm/gdm/whatever - you only want it for login ... I am not one with the words ... mind doing me an updated version that I can just add ? > BTW, I fully agree with separating pam_console in a different ebuild. This > would make the pam_console flag disappear, right? > Yup.
Created attachment 62863 [details, diff] pam-console-doc.patch > Yeah, should be added to login/xdm/gdm/whatever - you only want it for > login ... > I am not one with the words ... mind doing me an updated version that I can > just add ? What about this: Do not have any reference to pam_console in the pam.d files, instead, just add an einfo to the pam ebuild and clarify the README about enabling pam_console. This also plays well when pam_console gets its own ebuild, it's just a matter of moving the README and the einfo there. The patch above implements this (apart from removing the references to pam_console in the pam.d files). If it's ok, I can commit it.
Fine with me if you change the: ----- + Alternatively, you can add the line above to /etc/pam.d/system-auth so that + pam_console will be enabled everywhere. ----- to something like: ----- + Alternatively (but not recommended), you can add the line above to /etc/pam.d/system-auth + so that pam_console will be enabled everywhere. -----
Ok, committed.
*** Bug 73660 has been marked as a duplicate of this bug. ***
*** Bug 18599 has been marked as a duplicate of this bug. ***
*** Bug 107773 has been marked as a duplicate of this bug. ***
Can we also get the the line <console> 0600 <sound> 0600 root.audio in /etc/security/console.perms changed to 0660 as well?
This should be fixed now, and if it's not, single bugs for the packages should be filed. Has to be noted that pam-0.99 is unlikely to bring pam_console by itself anymore. There are a few other methods that can be used to achieve almost the same behaviour, and I'd rather give pam_console its own ebuild rather than using the main pam ebuild to build it.
