Bug 7227 - xdm and gdm steal devices for user upon login, e, since g /dev/cdrom
xdm and gdm steal devices for user upon login, e, since g /dev/cdrom
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
:
: 8898 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-22 09:33 EST by maavl
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-04 09:58:42 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 maavl 1999-11-22 09:33:57 EST
There are some bizarre things going on of which the main symptom is that I
cannot play CD's at home using xplaycd, unless I change the ownership
and/or permissions of /dev/cdrom (or rather the device it refers to, which
happens to be /dev/hdb), but I have to REDO this AFTER EACH REBOOT!

Trying to understand what is going on I can locate the problem, but I am
puzzled at the reasons this is happening as it does, or even if this is
unintended behaviour (as in a bug) or intended behaviour that just sucks
like hell.

What happens is that the first time somebody logs in an X session after a
reboot, she/he becomes owner of a whole bunch of devices, and their access
permissions are also modified. A selection of devices affected is
/dev/{audio,audio1,fd0,fd0D360,... ,hdb,midi00,mixer,sequencer,...}; I have
only recorded precise permission changes for /dev/hdb, where they are set
to 600 (brw-------), while I want them to be 666. I'm pretty sure it is xdm
who changes the ownership, not the user X session started by it, because
(1) it requires root permission to make the changes (2) the time shown by
`ls -lc --full-time /dev/hdb' is fairly consistently 1 second BEFORE the
access time of the (virtually empty) .xsession-errors file of the first
user to log in (and therefore owner of /dev/hdb). Need I say that it is
none of xdm's business to abuse its root privilege to tinker with device
ownerships and permissions?

Yet there are some indications that this is done with some mysterious
purpose in mind. Firstly, most of the affected devices seem to have
something to do with sound, as far as I can tell (I'm pretty sure that
/dev/hdb is actually accessed via /dev/cdrom, since on another linux box I
see this happening to /dev/hdc instead, which is again /dev/cdrom there).
Secondly, and even  weirder, the same phenomenon happens when I use gdm
instead of xdm, but even more aggressively: with gdm the ownership changes
with every login, and ownership is given (back) to root upon exit (at least
upon reboot, I haven't checked if it already happens upon session logout).

Could it be that these display managers find it necessary that the user
performing an X session be the exclusive owner of all audio devices during
that session? If so, they are wrong, because I can (and want to) have
multiple X sessions for multiple users simultaneously on different virtual
terminals (using two lines in /etc/X11/xdm/Xservers), and they can't all
own the devices, can they? In fact, the reason I am having the problem is
that my wife usually logs on to vt8 during the day, and so in the evening I
cannot play music from vt7, because the CD drive is hers! If every user is
to be allowed access to audio devices, this should be achieved by allowing
group or world access, not by stealing the device for the user upon login.
Comment 1 maavl 1999-11-22 11:22:59 EST
(1) This problem seems to be RedHat-specific (at least in its xdm variant),
since I don't see similar phenomena under Debian GNU/Linux.

(2) gdm does indeed give the devices to root upon session logout. I haven't yet
figured out how to install multiple X screens on different virtual consoles with
gdm, so I cannot tell how that influeneces things. When playing around switching
back and forth between xdm and gdm (I had to change runlevels back and forth to
do get init to do this) I did notice at some point that gdm no longer gave away
devices (nor did xdm). I cannot figure out just what gets refreshed at reboot so
as to reactivate this behaviour.
Comment 2 darkeye 1999-12-09 01:56:59 EST
I found the same problem, and it's _extremely_ annoying. I, as the admin of my
Linux box can (and want to) decide who has access to the cdrom. And I definately
don't want to give this role to some GUI. This behavior smells like Windows.

I just hope that this can be changed with a configuration option, but.. where?
Comment 3 maavl 1999-12-09 05:54:59 EST
I've figured this one out by now. Indeed it is not by accident, but by design,
but what a lousy design! The culprit is called pam_console, so it really does
not have much to do with xdm/gdm; it is a side affect beyond their control of
them asking authentication of the user. You can read all about pam_console's
dubious practices on its man page (section 8). It even says [after the first
user logs out]: "Then the race can start for the next user.  In practice, this
is not a problem; the physical console is not generally in use by many people at
the same time, and pam_console.so just tries to do the right thing in weird
cases." So it is weird that I use different virtual consoles for (X) sessions of
different people? I find this the single most useful aspect of virtual consoles,
the one thing no virtual desktopping window manager I have seen can can achieve
(nor of course can M$ Lose 95/98).

The file to edit to turn off this cruft is /etc/security/console.perms.
Just comment out lines like

<console>  0600 <sound>     0644 root.sys
<console>  0600 <cdrom>     0600 root.disk

In fact the ideal configuration is to comment out all lines. It would be even
better to throw out pam_console altogether, but that requires removing lines
from quite a few files in files /etc/pam.d/*. I've marked this bug as WONTFIX,
since I kinda doubt the RedHat is going to admit that pam_console does not
contain a bug, but rather _is_ one (besides they don't seem to be paying much
attention to this bug either). Here's a hint of a design that would be
acceptable: create a group console-users, make that the group of all
console-controled devices (and make them g+rw), and have a PAM module set the
group id to console-users when a user logs in on a console.
Comment 4 Göran Uddeborg 1999-12-21 06:00:59 EST
There IS indeed an xdm bug here, and I do think it should be fixed!  It is not a
matter of simultaneous use of the console by different users.

With xdm ONLY pam_console doesn't return files properly.  Logging in from a text
console and logging out works fine, and the first time anybody logs in via xdm
the files are changed correctly.  But when logging out they are not given back.

I have not looked at the code, but judging from an "strace" of the xdm process,
it appears to be a permission problem.  xdm changes user to the user logging in
before it tries to unregister with pam_console.  But without superuser
priviliges, it fails to do this.  And thus it appears as if the user is still
logged in.  I enclose an extract from the trace.
Comment 5 Göran Uddeborg 1999-12-21 06:04:59 EST
Hmm, how do I add an attachement to an already existing bug?  I couldn't find
any way.  But my file isn't too big, so I can add it as a comment instead.

        .
        .
        .
open("/var/lock/console.lock", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
write(4, "g\366ran", 5)                 = 5
close(4)                                = 0
open("/var/lock/console/gvran", O_RDWR|O_CREAT, 0600) = 4
alarm(20)                               = 0
fcntl(4, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
alarm(0)                                = 20
access("/var/lock/console/gvran", F_OK) = 0
fstat(4, {st_mode=S_IFREG|S_ISUID|04, st_size=0, ...}) = 0
write(4, "1", 1)                        = 1
close(4)                                = 0
        .
        .
        .
fork()                                  = 1779
write(1, "StartSession, fork succeeded 177"..., 34) = 34
write(1, "Client Started\n", 15)        = 15
wait4(-1, NULL, 0, NULL)                = 1779
--- SIGCHLD (Barnprocess avslutad) ---
write(1, "Source reset program /etc/X11/xd"..., 41) = 41
write(1, "source /etc/X11/xdm/Xreset\n", 27) = 27
fork()                                  = 1808
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 1808
--- SIGCHLD (Barnprocess avslutad) ---
kill(1313, SIGHUP)                      = 0
setgid(100)                             = 0
setuid(100)                             = 0
write(1, "RemoveUserAuthorization\n", 24) = 24
        .
        .
        .
open("/var/lock/console/gvran", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission
denied)
        .
        .
        .
Comment 6 maavl 1999-12-21 07:44:59 EST
Gvran, thanks for the information, and for mentioning "strace", which seems Neat
Stuff. I'll mark this bug as reopened (in case somebody at RedHat is listening).
BTW, the reason you can't add an attachement is that you are neither the
reporter nor the one the bug is assigned to. Fortunately, my Swedish is just
good enough to interpret the strace output (Barn=child, avslutad=closed). which
does not mean that I understand what exactly us going on..
Comment 7 Preston Brown 2000-02-03 23:44:59 EST
*** Bug 8898 has been marked as a duplicate of this bug. ***
Comment 8 Preston Brown 2000-02-04 09:58:59 EST
the insufficient permissions issue has been corrected for the next release.

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