Bug 59936 - console.perms breaks
console.perms breaks
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
: Security
: 71468 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-15 00:47 EST by Gabriel Schulhof
Modified: 2007-04-18 12:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-12 03:54:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gabriel Schulhof 2002-02-15 00:47:39 EST
Description of Problem:


Version-Release number of selected component (if applicable):
pam-0.75-19

How Reproducible:
Often

Steps to Reproduce:
1. Keep logging in as different users

Actual Results:
/dev entries that are supposed to get their permissions changed by console.perms do not get their permissions changed after a while

Expected Results:
Ownership of selected /dev entries should be given to the first console user who logs in, /every time/, not just the first couple.

Additional Information:
After logging in many different times as different users on various local ttys, the permissions on, say, /dev/dsp stop changing from user to user, for whoever happens to be the first user logged in at the console.  The user name I use, 'nix', is the one most often used, since I'm the most frequent user of the computer in question.  After logging in many times on various local ttys (X and otherwise), ownership of /dev files such as /dev/dsp remains mine even after I log out, the point at which it should revert to 600 root.root .

I know this because, when I log in remotely as root (a remote login will not trigger a change in permissions, nor a change in ownership), and do ls -l /dev/dsp, I find that the owner is still 'nix', instead of 600 root.root.

I tried removing /var/run/console.lock, followed by pam_console_apply.  I also tried pam_console_apply -r.  Running these worked (ownerships looked OK), but it didn't get the ownerships and permissions automagically changing again.  Now, if someone wants to play, say, Tux Racer, I have to log in as root and explicitly give them permission to use /dev/dsp.

Thanks for your help.
Comment 1 Gabriel Schulhof 2002-02-15 01:47:40 EST
I think I may have found both the cause and the resolution of the bug.

Cause:  When I log in as any user via X, I get console ownership and various other goodies.  When I kill X brutally (C-A-Backspace) instead of gracefully, Bad Things happen:

- /etc/X11/xdm/TakeConsole doesn't get executed
- /var/run/console.lock doesn't get removed
- /var/run/console now contains a file called 'nix' that contains 1 byte:'1'

Fix (as root): 
/etc/X11/xdm/TakeConsole
rm /var/run/console.lock
rm /var/run/console/nix1
pam_console_apply -r

Consequently, I have been able to completely and consistently reproduce the behaviour:

1. Log in remotely as root.
2. useradd -g users nix1
3. passwd nix1
4. Log into X via gdm locally as nix1
5. C-A-Backspace (kills X)

That's it, the ownership auto-assignment cycle is now broken, until (as mentioned):

[root@...]# /etc/X11/xdm/TakeConsole
[root@...]# rm /var/run/console.lock
[root@...]# rm /var/console/nix1
[root@...]# pam_console_apply -r

The crucial step seems to be
rm /var/console/nix1

Would it be possible/wise to run these steps from someplace where the exit status of X is within the scope of the script (Checkable via $? or some such).  By this I mean that you should include this kind of 'X-has-crashed-so-if-the-user-had-the-ownerships-then-fix-it-so-the-automagic-ownership-reassignment-works-again' check somewhere in the X/[xkg]dm-related scripts.

Are these steps enough ?  Am I missing something due to the fact that I'm not thoroughly familiar with the workings of these ownership assignments ?

Thanks for your support.
Comment 2 Willem Jan Palenstijn 2002-03-12 14:12:19 EST
(Using RH 7.2, pam-0.72-19, gdm-2.2.3.1-20)

AFAICT this is caused by somewhat of a problem in pam_console:

When you kill X with Ctrl-Alt-Backspace, the socket /tmp/.X11-unix/X0 (or X1, or
...) is removed.

Then, when pam_console.c:pam_sm_close_session is called (in my case from gdm's
gdm_slave_session_stop,gdm_verify_cleanup), it checks whether the 'tty' the user
was logged in to (ie. :0, :1, etc...) actually exists. In the X display case,
this translates to the existance of the mentioned /tmp/.X11-unix/X? file. This
check now clearly fails, and so the console use-count isn't decremented and
console.lock isn't removed, causing the problems mentioned in the original
bugreport.

To recap, the code path that causes this specific problem is:

pam_session.c:pam_close_session(), calls (through dispatch and all that)
pam_console.c:pam_sm_close_session(), calls 
config.y:check_console_name(), which checks the existance of /tmp/.X11-unix/X?
Comment 3 Mark J. Cox (Product Security) 2002-08-16 03:58:16 EDT
*** Bug 71468 has been marked as a duplicate of this bug. ***
Comment 4 Kjartan Maraas 2003-04-02 17:45:13 EST
It looks like this works ok in RHL 9 at least. I'm using gdm and I see
/tmp/X11-unix/X0 after killing X with ctrl+alt+backspace.

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