Bug 22034 - wrong owner of /dev entries
Summary: wrong owner of /dev entries
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdm
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-10 16:39 UTC by jmbastia
Modified: 2007-04-18 16:30 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-12-12 01:58:06 UTC
Embargoed:


Attachments (Terms of Use)

Description jmbastia 2000-12-10 16:39:47 UTC
I'm running RedHat 7.0 with XFree86 4.0.1 as shipped on the CDs, and using
gdm for a gui login.

Earlier this week, Netscape had frozen up on a user, so I hit
CTRL-ALT-BACKSPACE to kill the X server and log the user out.

Then I logged in to the system, and when I attempted to play some music,
both the mixer program and XMMS complained that the soundcard wasn't
configured properly.  I knew it was, and after hunting around for a bit, I
found that the user that was logged in when Netscape froze was still the
owner of /dev/mixer, /dev/dsp*, and a slew of other devices.

I su'd to root and changed the ownership to myself, and was able to play
music again.

However, the /dev entries' ownership is stuck now to whatever I chown them
to as root.  Earlier, whenever a user logged in, they became the owner of
certain /dev entries for that session.  Now that isn't happening anymore.

Comment 1 Havoc Pennington 2000-12-10 18:34:09 UTC
This is a usermode issue of some kind, reassigning.

Comment 2 jmbastia 2000-12-16 15:09:12 UTC
Recently, I had to reboot into Windows 95 for a moment.  I just noticed that the
ownership of the /dev entries appears to be working correctly again.  It seems a
reboot fixed the problem...  That's not supposed to happen with Unix.  :)

In any case, it's working again.

Comment 3 Lenny G. Arbage 2005-08-07 05:35:58 UTC
I have the same problem.  Can reproduce virtually every time by doing a
ctrl-alt-backspace in X (gnome) as one user, then logging back in as another...
 Suggest REOPEN and assign this to the right person.

Comment 4 Nalin Dahyabhai 2005-08-08 22:28:07 UTC
This sounds like a "gdm doesn't close the session if the X server exits
unexpectedly" problem, but I can't reproduce this either on a current release
(RHEL 4 or Fedora Core 4).  Which release are you still seeing this with?

Comment 5 Nalin Dahyabhai 2005-08-08 22:30:28 UTC
(Moving back to "gdm" for the sake of searching -- usermode isn't involved when
you log in or out.)

Comment 6 Lenny G. Arbage 2005-08-09 15:25:46 UTC
I'm seeing this on a FC2 box (perhaps it has been fixed in FC3 or 4).  I'll try
to come up with some steps for reproducing.

In the past, this has usually happened as a result of one user's X session
freezing up (last time, via my 1-yr old nephew's random pounding on the keyboard
on the gnome desktop).  Killing the X session with ctrl-alt-backspace gets back
to the login.

After not being able to get /dev to reassign automatically, I've tried
restarting gdm ('init 3') and even going all the way down to init 1 (checking to
make sure all non-essential procs went away) and then going back up to init
level 5.  Still no good.  The only way I've been able to get it to work again is
via reboot :( .

Comment 7 Nalin Dahyabhai 2005-08-09 17:59:15 UTC
Yes, the mechanism is the pam_console module, and it keeps track of who the
"owner" of the devices should be, and how many times that user is logged in,
using a reference count file in /var/run/console (it was /var/lock/console on
earlier releases).  The count is updated when the user in question logs in or
out (the logout seems to avoid detection here), the "owner" only changes when
the previous owner's count drops to 0, and the reference count is only reset at
reboot-time.

Comment 8 Nalin Dahyabhai 2005-08-09 18:32:48 UTC
I can confirm that this was still a problem in Fedora Core 2 -- the
Ctrl-Alt-Backspace after login method works on FC2 but not FC3, so my thinking
is that this was fixed somewhere between gdm 2.6.0.0 and 2.6.0.5.


Note You need to log in before you can comment on or make changes to this bug.