If someone logs in to a virtual terminal, ownership of many devices (/dev/dsp and /dev/scd0, notably, but others as well) gets changed to that user, and the devices chmod to be very restrictive. This is very annoying if another user happens to be logged in on another console (in X, for example) as that user suddenly loses the rights to use a bunch of devices -- no more sound, no more cdrom....
What you describe should not be happening... pam_console, the code that changes the device permissions, keeps track of logged in users, and if another user is already logged in on the console, then it is designed not to give the permissions to the next user. If you can give more details about what is happenning, including whether this happens reliably or only occasionally, which of xdm, kdm, or gdm you are using, and a description of precisely which steps you go through to replicate the problem, it will help us investigate.
We have the same problem. We use kdm to log in, but /dev/fd0, /dev/dsp etc remain owned by root with very restrictive access policies. If I also log in on a virtual terminal, I become the owner of these devices, but once I log out, ownership reverts to root. In reality it means that if I want to use devices like the floppy drive, I must log in on a VT, and try to remember to log out before I leave the computer. It looks like bug 2525 is another symptom of this bug.
This appears to be a problem in kdm and probably xdm as well. gdm does not have this problem, so a workaround until kdm/xdm updates are available is to use gdm. Install gdm if it is not already installed and then ln -sf ../../usr/bin/gdm /etc/X11/prefdm
The next release of X will contain a version of kdm which has fixed these problems.
*** Bug 3896 has been marked as a duplicate of this bug. *** If one switches the default console to xdm from gdm under redhat 6.0, the pam-console logout actions are not triggered properly and the ownership of /dev/dsp, /dev/cdrom, etc. get stuck with the first user to log in after a reboot. When that user logs out the following message is generated in /var/log/secure: Jul 4 12:57:28 myhost pam_console[786]: Could not open lock file /var/lock/console/sdh4, disallowing console access then on the next attempted login: Jul 4 12:57:58 myhost pam_console[872]: console file lock already in place /var/lock/console.lock
*** Bug 4039 has been marked as a duplicate of this bug. *** In xdm (and kdm) move code calling pam_close_session to top of function it is in. Make sure it is called with root privs. pam_console takes a "debug" argument that you can use to make sure that it works correctly. Should depend on pam >= 0.66-19
I totally agree with pbrown. Seems there is a bug with xdm (which I use) which causes pam_console to be executed with non-root privs. This results in the following message in /var/log/secure: /var/log/secure:Jul 15 06:21:12 dogbert pam_console[1600]: Could not open lock file /var/lock/console/fullung, disallowing console access /var/lock/console/fullung isn't unlinked (the console thus remains locked), so when next someone logs in, PAM doesn't set new permissions on the devices as detailed in /etc/security/console.perms. When is A fix coming out? :)