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 <my_ip>:/<path>/<to>/<dir>/snapshot 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): kernel-2.4.21-9.0.1.EL pam-0.75-51 glibc-2.3.2-95.6 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:
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.
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.
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. Thanks.
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.
Given that this problem is 18 months old, is there sufficient interest in this being investigated and possibly resolved?