Description of problem: Since the pam-0.99.6.2-3.26.el5 errata update, vsftp no longer allows non-anonymouns logins. Reverting to the original 0.99.6.2-3.14 release makes the problem go away. Version-Release number of selected component (if applicable): 0.99.6.2-3.26.el5 How reproducible: Always. Steps to Reproduce: 1. Install pam-0.99.6.2-3.26.el5 update on RHEL5. 2. "ftp localhost", and login using an unprivileged username and password. 3. Look at error messages, then "setenforce 0" and repeat step 2 for a successful login. 4. "setenforce 1", then step 2 fails again. 5. revert to pam-0.99.6.2-3.14 and step 2 succeeds again. Actual results: FTP client gives these errors after the user enters the password: 530 Login incorrect. Login failed. /var/log/secure shows these log entries: Nov 14 13:05:43 dave2 unix_chkpwd[21242]: could not get username from shadow (grdetil)) Nov 14 13:05:43 dave2 vsftpd: pam_unix(vsftpd:account): unix_update returned error 9 /var/log/audit/audit.log shows a log entry like this one, but no AVC messages are logged: type=USER_ACCT msg=audit(1195067023.947:3979): user pid=21228 uid=0 auid=4294967295 subj=system_u:system_r:ftpd_t:s0 msg='PAM: accounting acct=grdetil : exe="/usr/sbin/vsftpd" (hostname=dave2.scrc.umanitoba.ca, addr=140.193.80.133, terminal=ftp res=failed)' Expected results: A successful login, as with the pam-0.99.6.2-3.14 release, or with setenforce 0. Additional info: 1. The RHSA-2007:0555-8 security advisory says this: * pam_unix module security properties were improved. Functionality in the setuid helper binary, unix_chkpwd, which was not required for user authentication, was moved to a new non-setuid helper binary, unix_update. A look at the patches in the SRPM for the new release shows some pretty substantial changes to unix_chkpwd and pam_unix. I suspect one of these changes introduced the problem. 2. I've set the boolean option in selinux for vsftpd to be allowed access to users' home directories.
I should also add that the same login username works fine under ssh. I've compared /etc/pam.d/sshd to /etc/pam.d/vsftpd, and noticed that /etc/pam.d/sshd contained the line: password include system-auth while /etc/pam.d/vsftpd didn't. I tried adding that line, but it didn't make a difference.
Can you please attach a strace from vsftpd, when you try to log in? Do not use valuable password.
Created attachment 258821 [details] strace output from vsftpd child process during login
The process is running with correct uid so the problem is in the selinux-policy. Probably there is not a proper transition from ftpd_t to another context allowing reading /etc/shadow during the exec of unix_update. Note that the message 'unix_chkpwd[21242]: could not get username from shadow (grdetil)' is actually misleading and coming from unix_update not from unix_chkpwd - this is a small bug in unix_update.
OK, I'm a bit confused by this. I thought unix_update was split out of unix_chkpwd, for updating a password in /etc/shadow, and had nothing to do with checking passwords. Why would pam_unix call unix_update to verify my password? I thought that job remained with unix_chkpwd. What does vsftpd need to update that sshd doesn't? I did this... chcon system_u:object_r:chkpwd_exec_t /sbin/unix_update and now FTP logins work. But I guess next time some process does a restorecon in /sbin, that change will be reversed (back to sbin_t). It's odd that the failure of unix_update to execute, or to do its job (whatever that might be) after it executed, didn't generate any AVC message in audit.log. Is there anything else you'd like me to try, or should I just wait for a selinux-policy update to make the change permanent? Is chkpwd_exec_t even the correct selinux context for unix_update, or did I just open (or re-open) a hole by doing that? In any case, I think it's probably better than staying with the old version of pam, and certainly better than turning off selinux enforcing. Thanks for looking into this.
What version of selinux-policy are you running?
selinux-policy-targeted-2.4.6-30.el5 currently. I see there's an update release available, according to RHBA-2007:0544, but my system doesn't have it yet. I'll look into it.
Yes please update to nux-policy-targeted-2.4.6-106.el5-1.3
Done. Works like a charm now. vsftpd is happy, and so am I. Thanks for your help and sorry to waste your time. I'll pay closer attention to the errata next time and make sure I have ALL the updates.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0465.html