From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Tried to disable SELinux, but once I finally did, the problem still remains. Denies me whenever 'passwd' is executed. The lockfile in /etc/.pwd.lock wont go away. --- [root@localhost ~]# adduser pumpkin [root@localhost ~]# passwd pumpkin Changing password for user pumpkin. New UNIX password: Retype new UNIX password: passwd: Authentication failure --- very perplexing Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Type 'passwd' 2. put in the new passwords 3. Profit! <enter> Actual Results: passwd: Authentication failure Expected Results: changed the password Additional info: SELinux seems pretty horrible, i wish the installer had told me the kind of troulbes it would cause for me.
Are you seeing AVC messages? Was this a fresh install or an upgrade?
i am experiencing identically the same behavior. it was a fresh install, and i get NO AVC messages whatsoever... selinux is in "permissive" mode. i'm thinking this is more likely related to pam than to selinux directly. were there altered pam directives put in place when selinux gets installed, or something similar to that?
Are you running with targeted or strict policy. In permissive mode or targeted policy the passwd command runs in a unconfined mode. so there really should be no difference. What type of authentication are you using? Dan
I have the same issue. Mine install of FC3 was an upgrade from FC2. I am using: SELINUX=enforcing SELINUXTYPE=targeted in /etc/sysconfig/selinux Im am using MD5 Passwords and shadow passwords and PAM (all the defaults) no ldap, nis, etc for authentication.
Did you relabel after the upgrade?
No, I do not know what that is.
touch /.autorelabel reboot If you turn on selinux you need to relabel your file system. In the SELinux world, all files have a label associated with them. You can do a ls -Z to see the labels. The labels (or contexts) are used to make Access control decisions. If you upgraded most of your labels are wrong. http://fedora.redhat.com/docs/selinux-faq-fc3/
That worked on one machine I upgraded to fc3, but not on another. Both machines are set to: SELINUX=enforcing SELINUXTYPE=targeted in /etc/sysconfig/selinux I have not yet read the selinux faq, so I suspect the reason for the 2nd machine not yet working with selinux is answered there.
This had me going for a while, not being able to set a password for my own personal (non-root) user account. Here's what I found (commands and output as shown): [root@out ~]# passwd john Changing password for user john. New UNIX password: Retype new UNIX password: passwd: Authentication failure [root@out ~]# ls -Zl /etc/shadow* -r-------- 1 root root 1288 Jan 28 23:25 /etc/shadow -rw------- 1 system_u:object_r:shadow_t root root 1288 Jan 28 23:23 /etc/shadow- [root@out ~]# restorecon /etc/shadow [root@out ~]# passwd john Changing password for user john. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@out ~]# passwd john Changing password for user john. New UNIX password: Retype new UNIX password: passwd: Authentication failure [root@out ~]# So, something (passwd? pam?) is losing the context on /etc/shadow with the effect that only one person can change one password until someone does a restorecon. I've a new FC3 installation (not upgrade), reasonably up2date (it was yesterday), passwd 0.68-10, pam 0.77-66.2. I think SELinux is supposed to be being permissive (well that's what I put in /etc/selinux/config) with the targeted policy, but the above behaviour makes me think it must be enforcing. That's not the point here though; passwd (or whatever) breaking the security context is the point.
Oh, if it makes any difference, my root filesystem uses ReiserFS over lvm.
ReiserFS is not supported with SELinux by FC3. I believe there are problems with the Reiser File system and exteneded attributes. Contact the SELinux.gov mailing list if you need help. Dan
You shouldn't have closed this; I may be using ReiserFS but the original reporter didn't say that. Also, I may be using ReiserFS but it looks like it's is supporting extended attributes correctly in this instance. It sounds as if you may have been a little quick to judge; please look again. Durka, please comment.
Sorry we have a hole bunch of these with the same symptoms and so far everyone is reiserfs. Which we don't test or support. If Durka states otherwise I will take a look at it. Dan
I'm getting the same behavior with ext3 on a kitchen-sink FC3 install. To reproduce: - new FC3 install, add "everything". - set the root password on install - reboot, complete install, yadda yadda yadda - update all rpms (kernel included) as of 7 April 2005, rhn/sources = yum fedora-core-3 http://download.fedora.redhat.com/pub/fedora/linux/core/3/$ARCH/os/) yum updates-released-fc3 http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/$ARCH/ - attempt to set new root password with "passwd": # passwd Changing password for user root. New UNIX password: Retype new UNIX password: passwd: Authentication failure # I may be wrong on this but I think the default SELinux and PAM policies require labels on *both* /etc/passwd and /etc/shadow, but... # restorecon -o /tmp/fubar -n /etc/shadow # cat /tmp/fubar /etc/shadow # restorecon -o /tmp/fubar -n /etc/passwd # cat /tmp/fubar # ls -lZ /etc/passwd -rw-r--r-- root root system_u:object_r:etc_t /etc/passwd # ls -lZ /etc/shadow -r-------- root root /etc/shadow # Any other data I should gather before running fixfiles/restorecon?
/etc/shadow has no context on it? # restorecon -o /tmp/fubar -n /etc/shadow # cat /tmp/fubar /etc/shadow # restorecon -o /tmp/fubar -n /etc/passwd # cat /tmp/fubar I think you need a -v qualifier to do what you expect. /etc/passwd should be etc_t but shadow should be shadow_t rhn might be the problem here. If that is not running in rpm context, or some app rewrote the /etc/shadow from a file system that does not support file context.
A 'restorecon' worked just fine on clone of the problem system's physical volumes. I have a hunch that the core problem was a failed auto-label on first boot after the install; spot checking output from 'fixfiles -R -a' in 'check' mode on the clone system looks like there were no labels on any package members written during/after the base PAM install. Me, I'm blaming planetary alignment.
Na, that's habit. I wanted file output rather than stdout. I don't think the problem is rhn -- it was used to update packages which have member correctly labeled. This looks more like a one-time failure to me. (In reply to comment #15) > /etc/shadow has no context on it? > > # restorecon -o /tmp/fubar -n /etc/shadow > # cat /tmp/fubar > /etc/shadow > # restorecon -o /tmp/fubar -n /etc/passwd > # cat /tmp/fubar > > I think you need a -v qualifier to do what you expect. > > /etc/passwd should be etc_t but shadow should be shadow_t > > rhn might be the problem here. If that is not running in rpm context, or some > app rewrote the /etc/shadow from a file system that does not support file context. > > > >
Odd. Testing rhn/up2date involvement for package mc, which happens to be in the previous test output and have an update available: - 'fixfiles -R mc check' reported resets required for /usr/share/mc/bin /usr/share/mc/bin/mc-wrapper.csh /usr/share/mc/bin/mc.sh /usr/share/mc/bin/mc.csh /usr/share/mc/bin/mc-wrapper.sh - 'up2date -u mc' updated mc to mc-4.6.1-0.13.FC3 - 'fixfiles -R mc check' now reports no problems
I was backward in my earlier statement that the problem was limited to a subset of RPM installs after PAM ... it's the packages that have been *updated* that *do* have correct EAs. RHN and up2date have been populating missing EAs on top of what appears to be an install sans any labels. If I recall, there was a pre-release FC3 bug that caused system-config-securitylevel to not create .autorelabel; the install media is not test release, but the dates are 3 Nov 2004 and the bug was still being reported mid-Nov. If the bug made it into the first cut of major release, that would explain all of the above. I'll pull a fresh copy of the dist and repeat the test, but I think we have a culprit; the auto-label was never performed at firstboot.