Hide Forgot
# strace -o passwd.log passwd bob Changing password for user bob. New password: BAD PASSWORD: it is WAY too short BAD PASSWORD: is a palindrome Retype new password: passwd: all authentication tokens updated successfully. # grep /dev/ passwd.log |head -n 100 readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10 stat("/dev/pts/0", 0x7fff129291e0) = -1 EACCES (Permission denied) stat("/dev/pts", 0x7fff129291e0) = -1 EACCES (Permission denied) stat("/dev/.", {st_mode=S_IFDIR|0755, st_size=3540, ...}) = 0 stat("/dev/..", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 stat("/dev/hidraw1", 0x7fff12929080) = -1 EACCES (Permission denied) stat("/dev/hidraw0", 0x7fff12929080) = -1 EACCES (Permission denied) stat("/dev/vcsa7", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 135), ...}) = 0 stat("/dev/vcs7", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 7), ...}) = 0 stat("/dev/vcsa2", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 130), ...}) = 0 stat("/dev/vcs2", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 2), ...}) = 0 stat("/dev/vcsa4", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 132), ...}) = 0 stat("/dev/vcs4", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 4), ...}) = 0 stat("/dev/vcsa5", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 133), ...}) = 0 stat("/dev/vcs5", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 5), ...}) = 0 stat("/dev/vcsa6", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 134), ...}) = 0 stat("/dev/vcs6", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 6), ...}) = 0 stat("/dev/vcsa3", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 131), ...}) = 0 stat("/dev/vcs3", {st_mode=S_IFCHR|0660, st_rdev=makedev(7, 3), ...}) = 0 stat("/dev/v4l", {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0 stat("/dev/video0", 0x7fff12929080) = -1 EACCES (Permission denied) stat("/dev/media0", 0x7fff12929080) = -1 EACCES (Permission denied) ... This causes Bug 739301 - SELinux is preventing /usr/bin/passwd from 'getattr' accesses on the chr_file /dev/autofs - and many other avcs I guess it is caused by some pam plugin? # rpm -q passwd passwd-0.78-3.fc15.x86_64 # rpm -qf /lib*/security/pam_*.so|sort|uniq ConsoleKit-libs-0.4.5-1.fc15.x86_64 fprintd-pam-0.2.0-3.fc15.x86_64 gnome-keyring-pam-3.1.91-1.fc16.x86_64 libcap-2.22-1.fc15.x86_64 pam-1.1.4-4.fc16.x86_64 pam_pkcs11-0.6.2-7.fc15.x86_64 passwdqc-1.2.2-2.fc15.x86_64 samba-winbind-clients-3.6.0-69rc2.fc16.1.x86_64 sssd-client-1.6.1-1.fc16.x86_64 systemd-35-1.fc16.x86_64
This is a regression in selinux-policy. PAM modules have to be able to call ttyname() which is doing this stat-ing if the initial stat("/dev/pts/0", 0x7fff129291e0) fails.
Well, AFAIK we haven't had a rule for this. So passwd needs to stat all in /dev?
No, as I wrote above - passwd needs to be able to stat the tty device it is run on, because it calls ttyname() from glibc. If ttyname() is getting stat("/dev/pts/0", 0x7fff129291e0) = -1 EACCES (Permission denied) as in the strace above, then it proceeds with stating all dentries in /dev/pts and then /dev in a an attempt to find the tty. If it makes any sense or not, I do not know - glibc developers would have to say why the ttyname() implementation does what it does. However it is certain that passwd was able to stat("/dev/pts/0") at least on F14 without problems. So there must have been some change in the selinux policy (labelling /dev/pts/* or whatever) that caused this regression.
Let's close this bug. I think the problem is Mads ran restorecon on /dev which causes this issue.
Huh, I did not run restorecon on /dev and I see the same failures in passwd strace on my F16 machine. Reopening. And BTW, running restorecon on system-managed directories should not break things.
How is labeled /dev/pts/* # ls -Z /dev/pts
crw--w----. root tty unconfined_u:object_r:user_devpts_t:s0 /dev/pts/0
It seems to be now working fine with the current selinux policy on F16.