Bug 3743 - console login grabs ownership of too many things, resets permissions
console login grabs ownership of too many things, resets permissions
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
:
: 3896 4039 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-25 21:01 EDT by Matthew Miller
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-15 17:24:02 EDT
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 Matthew Miller 1999-06-25 21:01:25 EDT
If someone logs in to a virtual terminal, ownership of many
devices (/dev/dsp and /dev/scd0, notably, but others as
well) gets changed to that user, and the devices chmod to be
very restrictive. This is very annoying if another user
happens to be logged in on another console (in X, for
example) as that user suddenly loses the rights to use a
bunch of devices -- no more sound, no more cdrom....
Comment 1 Michael K. Johnson 1999-07-13 11:33:59 EDT
What you describe should not be happening...  pam_console, the code
that changes the device permissions, keeps track of logged in users,
and if another user is already logged in on the console, then it is
designed not to give the permissions to the next user.

If you can give more details about what is happenning, including
whether this happens reliably or only occasionally, which of xdm,
kdm, or gdm you are using, and a description of precisely which
steps you go through to replicate the problem, it will help us
investigate.
Comment 2 schiotz 1999-07-14 05:00:59 EDT
We have the same problem.  We use kdm to log in, but /dev/fd0,
/dev/dsp etc remain owned by root with very restrictive access
policies.  If I also log in on a virtual terminal, I become the owner
of these devices, but once I log out, ownership reverts to root.

In reality it means that if I want to use devices like the floppy
drive, I must log in on a VT, and try to remember to log out before I
leave the computer.

It looks like bug 2525 is another symptom of this bug.
Comment 3 Michael K. Johnson 1999-07-15 14:44:59 EDT
This appears to be a problem in kdm and probably xdm as well.
gdm does not have this problem, so a workaround until kdm/xdm
updates are available is to use gdm.
Install gdm if it is not already installed and then
ln -sf ../../usr/bin/gdm /etc/X11/prefdm
Comment 4 Preston Brown 1999-07-15 17:24:59 EDT
The next release of X will contain a version of kdm which has fixed
these problems.
Comment 5 Preston Brown 1999-07-15 17:26:59 EDT
*** Bug 3896 has been marked as a duplicate of this bug. ***

If one switches the default console to xdm from gdm
under redhat 6.0, the pam-console logout actions are
not triggered properly and the ownership of /dev/dsp,
/dev/cdrom, etc. get stuck with the first user to
log in after a reboot.

When that user logs out the following message is generated
in /var/log/secure:
Jul  4 12:57:28 myhost pam_console[786]: Could not open lock
file /var/lock/console/sdh4, disallowing console access

then on the next attempted login:
Jul  4 12:57:58 myhost pam_console[872]: console file lock
already in place /var/lock/console.lock
Comment 6 Preston Brown 1999-07-15 17:30:59 EDT
*** Bug 4039 has been marked as a duplicate of this bug. ***

In xdm (and kdm) move code calling pam_close_session to
top of function it is in.  Make sure it is called with
root privs.  pam_console takes a "debug" argument that
you can use to make sure that it works correctly.

Should depend on pam >= 0.66-19
Comment 7 Albert Strasheim 1999-07-16 04:10:59 EDT
I totally agree with pbrown@redhat.com.

Seems there is a bug with xdm (which I use) which causes pam_console
to be executed with non-root privs. This results in the following
message in /var/log/secure:

/var/log/secure:Jul 15 06:21:12 dogbert pam_console[1600]: Could not
open lock file /var/lock/console/fullung, disallowing console access

/var/lock/console/fullung isn't unlinked (the console thus remains
locked), so when next someone logs in, PAM doesn't set new permissions
on the devices as detailed in /etc/security/console.perms.

When is A fix coming out? :)

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