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):
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
4. "setenforce 1", then step 2 fails again.
5. revert to pam-0.99.6.2-3.14 and step 2 succeeds again.
FTP client gives these errors after the user enters the password:
530 Login incorrect.
/var/log/secure shows these log entries:
Nov 14 13:05:43 dave2 unix_chkpwd: could not get username from shadow
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
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=188.8.131.52, terminal=ftp res=failed)'
A successful login, as with the pam-0.99.6.2-3.14 release, or with setenforce 0.
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
Can you please attach a strace from vsftpd, when you try to log in? Do not use
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: 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
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.