There are some bizarre things going on of which the main symptom is that I cannot play CD's at home using xplaycd, unless I change the ownership and/or permissions of /dev/cdrom (or rather the device it refers to, which happens to be /dev/hdb), but I have to REDO this AFTER EACH REBOOT! Trying to understand what is going on I can locate the problem, but I am puzzled at the reasons this is happening as it does, or even if this is unintended behaviour (as in a bug) or intended behaviour that just sucks like hell. What happens is that the first time somebody logs in an X session after a reboot, she/he becomes owner of a whole bunch of devices, and their access permissions are also modified. A selection of devices affected is /dev/{audio,audio1,fd0,fd0D360,... ,hdb,midi00,mixer,sequencer,...}; I have only recorded precise permission changes for /dev/hdb, where they are set to 600 (brw-------), while I want them to be 666. I'm pretty sure it is xdm who changes the ownership, not the user X session started by it, because (1) it requires root permission to make the changes (2) the time shown by `ls -lc --full-time /dev/hdb' is fairly consistently 1 second BEFORE the access time of the (virtually empty) .xsession-errors file of the first user to log in (and therefore owner of /dev/hdb). Need I say that it is none of xdm's business to abuse its root privilege to tinker with device ownerships and permissions? Yet there are some indications that this is done with some mysterious purpose in mind. Firstly, most of the affected devices seem to have something to do with sound, as far as I can tell (I'm pretty sure that /dev/hdb is actually accessed via /dev/cdrom, since on another linux box I see this happening to /dev/hdc instead, which is again /dev/cdrom there). Secondly, and even weirder, the same phenomenon happens when I use gdm instead of xdm, but even more aggressively: with gdm the ownership changes with every login, and ownership is given (back) to root upon exit (at least upon reboot, I haven't checked if it already happens upon session logout). Could it be that these display managers find it necessary that the user performing an X session be the exclusive owner of all audio devices during that session? If so, they are wrong, because I can (and want to) have multiple X sessions for multiple users simultaneously on different virtual terminals (using two lines in /etc/X11/xdm/Xservers), and they can't all own the devices, can they? In fact, the reason I am having the problem is that my wife usually logs on to vt8 during the day, and so in the evening I cannot play music from vt7, because the CD drive is hers! If every user is to be allowed access to audio devices, this should be achieved by allowing group or world access, not by stealing the device for the user upon login.
(1) This problem seems to be RedHat-specific (at least in its xdm variant), since I don't see similar phenomena under Debian GNU/Linux. (2) gdm does indeed give the devices to root upon session logout. I haven't yet figured out how to install multiple X screens on different virtual consoles with gdm, so I cannot tell how that influeneces things. When playing around switching back and forth between xdm and gdm (I had to change runlevels back and forth to do get init to do this) I did notice at some point that gdm no longer gave away devices (nor did xdm). I cannot figure out just what gets refreshed at reboot so as to reactivate this behaviour.
I found the same problem, and it's _extremely_ annoying. I, as the admin of my Linux box can (and want to) decide who has access to the cdrom. And I definately don't want to give this role to some GUI. This behavior smells like Windows. I just hope that this can be changed with a configuration option, but.. where?
I've figured this one out by now. Indeed it is not by accident, but by design, but what a lousy design! The culprit is called pam_console, so it really does not have much to do with xdm/gdm; it is a side affect beyond their control of them asking authentication of the user. You can read all about pam_console's dubious practices on its man page (section 8). It even says [after the first user logs out]: "Then the race can start for the next user. In practice, this is not a problem; the physical console is not generally in use by many people at the same time, and pam_console.so just tries to do the right thing in weird cases." So it is weird that I use different virtual consoles for (X) sessions of different people? I find this the single most useful aspect of virtual consoles, the one thing no virtual desktopping window manager I have seen can can achieve (nor of course can M$ Lose 95/98). The file to edit to turn off this cruft is /etc/security/console.perms. Just comment out lines like <console> 0600 <sound> 0644 root.sys <console> 0600 <cdrom> 0600 root.disk In fact the ideal configuration is to comment out all lines. It would be even better to throw out pam_console altogether, but that requires removing lines from quite a few files in files /etc/pam.d/*. I've marked this bug as WONTFIX, since I kinda doubt the RedHat is going to admit that pam_console does not contain a bug, but rather _is_ one (besides they don't seem to be paying much attention to this bug either). Here's a hint of a design that would be acceptable: create a group console-users, make that the group of all console-controled devices (and make them g+rw), and have a PAM module set the group id to console-users when a user logs in on a console.
There IS indeed an xdm bug here, and I do think it should be fixed! It is not a matter of simultaneous use of the console by different users. With xdm ONLY pam_console doesn't return files properly. Logging in from a text console and logging out works fine, and the first time anybody logs in via xdm the files are changed correctly. But when logging out they are not given back. I have not looked at the code, but judging from an "strace" of the xdm process, it appears to be a permission problem. xdm changes user to the user logging in before it tries to unregister with pam_console. But without superuser priviliges, it fails to do this. And thus it appears as if the user is still logged in. I enclose an extract from the trace.
Hmm, how do I add an attachement to an already existing bug? I couldn't find any way. But my file isn't too big, so I can add it as a comment instead. . . . open("/var/lock/console.lock", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 write(4, "g\366ran", 5) = 5 close(4) = 0 open("/var/lock/console/gvran", O_RDWR|O_CREAT, 0600) = 4 alarm(20) = 0 fcntl(4, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 alarm(0) = 20 access("/var/lock/console/gvran", F_OK) = 0 fstat(4, {st_mode=S_IFREG|S_ISUID|04, st_size=0, ...}) = 0 write(4, "1", 1) = 1 close(4) = 0 . . . fork() = 1779 write(1, "StartSession, fork succeeded 177"..., 34) = 34 write(1, "Client Started\n", 15) = 15 wait4(-1, NULL, 0, NULL) = 1779 --- SIGCHLD (Barnprocess avslutad) --- write(1, "Source reset program /etc/X11/xd"..., 41) = 41 write(1, "source /etc/X11/xdm/Xreset\n", 27) = 27 fork() = 1808 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 1808 --- SIGCHLD (Barnprocess avslutad) --- kill(1313, SIGHUP) = 0 setgid(100) = 0 setuid(100) = 0 write(1, "RemoveUserAuthorization\n", 24) = 24 . . . open("/var/lock/console/gvran", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied) . . .
Gvran, thanks for the information, and for mentioning "strace", which seems Neat Stuff. I'll mark this bug as reopened (in case somebody at RedHat is listening). BTW, the reason you can't add an attachement is that you are neither the reporter nor the one the bug is assigned to. Fortunately, my Swedish is just good enough to interpret the strace output (Barn=child, avslutad=closed). which does not mean that I understand what exactly us going on..
*** Bug 8898 has been marked as a duplicate of this bug. ***
the insufficient permissions issue has been corrected for the next release.