From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Description of problem: su - user from root fails for some (but not all) values of user. We have been unable to correlate the characteristics of the users (UID, home directory, etc) to predict success or failure, none of whom have valid shells on the box in question. (User info is retrieved via LDAP and authenticated against Kerberos, although in this example no authentication should occur.) This can be corrected by applying the following patch to /etc/pam.d/su: 16c16,17 < account sufficient /lib/security/$ISA/pam_permit.so --- > account sufficient pam_krb5.so > account required pam_unix.so Version-Release number of selected component (if applicable): pam-0.77-66.5 How reproducible: Always Steps to Reproduce: 1. su --shell=/bin/sh username -c uptime (Reproducible always for any user which fails.) Actual Results: su: incorrect password Expected Results: 14:26:09 up 41 days, 5:24, 3 users, load average: 0.00, 0.00, 0.00 Additional info: This might be related to or a dupe of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164794 Note however that we must disable both pam_krb5 and pam_unix.
Could you please attach you /etc/pam.d/su and /etc/pam.d/system-auth? Also are there any log messages in /var/log/messages or secure when the su - xxxx command fails?
Created attachment 119802 [details] Original /etc/pam.d/su
Created attachment 119803 [details] Modified /etc/pam.d/su
Created attachment 119804 [details] /etc/pam.d/system-auth
The only entries were of the form Oct 10 14:26:09 soyvlaki su(pam_unix)[28071]: session opened for user xxxx b y benno(uid=0) Oct 10 14:26:09 soyvlaki su(pam_unix)[28071]: session closed for user xxxx (even with 'debug' flags set for the pams in the stack).
Created attachment 119849 [details] Original /etc/pam.d/su Attachment 119802 [details] was the wrong file.
I think this bug may be invalid, based on local configuration changes I've discovered. I'll reopen it if I'm wrong.
It's partly invalid (removing the pam_unix is never the right thing, instead the broken_shadow option should be used when the accounts authenticated against kerberos have wrong 'x' entry in /etc/passwd - *K* should be there) and partly a duplicate of bug 164794 which is a real bug (this is when removing pam_krb5 from account helps).