Bug 118985 - pam_console fails to give device ownership for diskless clients
pam_console fails to give device ownership for diskless clients
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Staubach
Depends On:
  Show dependency treegraph
Reported: 2004-03-23 11:39 EST by David J. Bianco
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-12 15:29:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David J. Bianco 2004-03-23 11:39:59 EST
Description of problem:

I have a diskless RHEL3 WS system with all the latest patches
(as of March 16 2004).  When a user logs in on the console (either
in text mode or in GDM), the system fails to set the audio, floppy
and cdrom device ownership so they can be used by the console user.

I have run "strace -f" on the mingetty program on that tty, and
have verified that the pam_console is being called, and that it
tries to chown() the devices.  As an example, here is the section
where it tries to set the ownership of the floppy device:

lstat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0),
...}) = 0
chown32("/dev/fd0", 4902, -1)           = 0

As you can see, the device exists (lstat64 returned OK), and the 
chown operation completed without error.  However, the file's 
permission is:

brw-rw----    1 root     root       2,   0 Mar 16 16:12 /dev/fd0

Just to show that the filesystem is mounted properly:

dlcc6:/home/bianco> df -h /dev/.
Filesystem            Size  Used Avail Use% Mounted on
                       60G   22G   39G  36% /dev

I'm not sure if this is a bug in the kernel or in the glibc, but
there's something weird going on here, and it's keeping me from
being able to deploy my diskless clients.  Any ideas?

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


How reproducible:

It happens every time

Steps to Reproduce:
1.  Build a diskless client
2.  Log in on the console (text or X) as a normal user
3.  Watch the device files be owned by the wrong person
Actual results:

The device files (eg, /dev/fd0) continue to be owned by root.root,
mode 660.

Expected results:

The device files should be owned by the console user (uid 4902 in
my example above), mode 0660.

Additional info:
Comment 1 David J. Bianco 2004-03-23 11:42:38 EST
Sorry for the immediate update.  I forgot to add that the diskless
client boots via tftp/PXE from an RHEL3 box, but the actual files
are on a Netapp fileserver.  I don't know if this makes a difference,
because I think the problem is somewhere on the Linux side, but I
figure I should add it for completeness.
Comment 2 Tomas Mraz 2004-11-16 13:38:20 EST
If the pam_console calls chown and it doesn't fail and the device
isn't really chowned, how could this be a bug in pam?
I'd bet on that it is some misconfiguration.
Comment 3 Ernie Petrides 2004-11-18 17:08:57 EST
David, thanks for the bug report.  Could you please try to chown
/dev/fd0 from root (to uid 4902) manually to see if this takes effect?

If that doesn't work, I'll reassign this to someone who works on
the associated file system (is it NFS?).

If that does work, then it's not a kernel problem, so please give
me some advice on which component should get this bug.

Comment 4 David J. Bianco 2004-11-19 10:04:56 EST
I tried this manually, and it worked fine:

dlcc4:/home/bianco> lag /dev/fd0
brw-rw----    1 root     root       2,   0 Oct 11 13:28 /dev/fd0
dlcc4:/home/bianco> sudo chown 4902 /dev/fd0
dlcc4:/home/bianco> lag /dev/fd0
brw-rw----    1 bianctst root       2,   0 Oct 11 13:28 /dev/fd0
dlcc4:/home/bianco> sudo chown root /dev/fd0
dlcc4:/home/bianco> lag /dev/fd0
brw-rw----    1 root     root       2,   0 Oct 11 13:28 /dev/fd0

I don't know if it's a kernel problem or not.  Perhaps it's a 
PAM problem, or a glibc problem, or an NFS problem, or any of a 
number of other components that are involved in the process.
Comment 6 Peter Staubach 2005-09-21 09:55:14 EDT
Given that this problem is 18 months old, is there sufficient interest in this
being investigated and possibly resolved?

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