+++ This bug was initially created as a clone of Bug #230823 +++ From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070221 Red Hat/1.5.0.10-0.1.el4 Firefox/1.5.0.10 Description of problem: I dont really know if this is a kernel bug but it didn't start happening until after I upgraded to the 2.6.9-42.0.10.ELsmp kernel. When a user logs in from the console, may devices such as /dev/mixer and /dev/floppy change ownership to the console user, which is normal. However, sometimes after the user logs out, the ownership permissions are not changed back to root. Version-Release number of selected component (if applicable): 2.6.9-42.0.10.ELsmp How reproducible: Sometimes Steps to Reproduce: 1. Log in as a user from the console. 2. Log out. 3. Log in as another user from the console. 4. Do dir /dev . Actual Results: Many devices are still owned by the previous user. Expected Results: Devices should be owned by the current user. Additional info: -- Additional comment from adebened on 2007-03-03 01:20 EST -- I experimented a bit more and the problem seems to be triggered by when a second user logs into the console. For example, a user is logged in at the text login (cntl-F5) and another user is logged in at the graphical login (cntl-F7). When one of these users logs out, ownership is not always released and does not get fixed when all users log out. Granted, it is rare that two users will ever e logged in at the console but sometimes it is useful to log in two users for testing purposes (say root and a regular user). I cant always reproduce it. It seems to be related to which user logs in and which user logs out first (the graphical or the text one) but it has happened several times. Once the problem occurs, logging in as root does not reset ownership to root. Thanks, Andrew -- Additional comment from jbaron on 2007-03-12 13:57 EST -- hmm, so if you go back to an older kernel this goes away? what version would that be so we can identify what broke. thanks. -- Additional comment from adebened on 2007-03-12 21:13 EST -- Hi. I cant reboot at the moment due to user jobs running but I experimented a bit more with this. It seems more probable now that it's a pam bug and not kernel. I may not have noticed it in previous kernels just by not looking. Here are the exact steps to produce the issue as well as how to fix it without rebooting: 1) log in a user from the text login (cntl-alt-f5). 2) log in another user from the graphical login (cntl-alt-f7). 3) log out the text-login user. 4) log out the graphical login user. 5) log back in the graphical login user (user of step 2). 6) "ls -laF /dev" and notice that a bunch of devices are still owned by the original text login user (user of step 1). 7) As root do a "pam_console_apply -r", this resets the device ownerships to root. 8) remove the files in /var/run/console/ 9) log out and now everything is happy when you log back in again. If you skip step 8 the devices still remain property of root when a user logs in again. Thanks, Andrew -- Additional comment from tmraz on 2007-03-23 06:43 EST -- Found the cause - it is a bug in pam_console which was always there. I don't know why nobody found it before.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Your simplified instructions aren't right. Here are the full steps to reproduce: 1. logout all users (except root) from all console devices (including gdm). 2. clear /var/run/console if it isn't empty 3. login user 1 (he obtains console.lock) 4. login user 2 5. logout user 1 6. logout user 2 (/var/run/console/user2 is not removed so pam_console thinks that the user stayed logged in on the console) 5. login user 2 (he obtains console.lock) 6. logout user 2 (he will have the console.lock forever due to the imbalance of logins/logouts)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0555.html