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
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
*** 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
Jul 4 12:57:28 myhost pam_console: 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: 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 email@example.com.
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: 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? :)