Red Hat Bugzilla – Bug 233581
CVE-2007-1716 Ownership of devices not returned to root after logout from console
Last modified: 2007-11-30 17:07:42 EST
+++ 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:188.8.131.52) Gecko/20070221
Red Hat/184.108.40.206-0.1.el4 Firefox/220.127.116.11
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):
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 .
Many devices are still owned by the previous user.
Devices should be owned by the current user.
-- Additional comment from firstname.lastname@example.org 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.
-- Additional comment from email@example.com 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 firstname.lastname@example.org 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
-- Additional comment from email@example.com 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
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
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.