Bug 14730
| Summary: | pam_unix.so must have shadow file to pass account component for non local users | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Erik J Burckart <ejburcka> |
| Component: | pam | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | gafton, herrold |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-07-28 18:19:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Erik J Burckart
2000-07-27 14:40:33 UTC
Run "getent passwd ejburcka". Does your user information have an "x" in the encrypted password field? This is a special character which specifically means "see the shadow file". If the pam_unix module sees this and can't read the user's information, you get an error from the account management function. If you're using Kerberos, this field is theoretically supposed to be "*K*" to signal that fact, though the pam_krb5 module (and I assume the pam_afs module also) does not enforce this. Thanks for looking into that. This brings me to the question, why does this not work the same way for pam_pwdb? When I replace the pam_unix with pam_pwdb in system-auth, I get passed just fine. Is one of them doing the wrong thing or are they intentionally designed different? Thanks, Erik You could say either that pam_pwdb was incorrect for not checking that, or that pam_unix is being unnecessarily paranoid. I actually can't decide whether pam_unix should or shouldn't be doing this check. On the one hand, it's different. On the other, it's probably correct. Is this in fact what is causing the behavior you're seeing? Yes...recreated many times on a couple of machines. Either pwdb isn't *secure* enough or pam_unix is just more secure. But I can definitely get passed by one module(pwdb) where the other(unix) continually fails authorization. This is why I thought it was a bug somewhere...or intentionally made different? It seems to be a valid check...but not one I have seen before (and one that is going to cause me to edit a 1000+ line passwd file.) How about this awk invocation?
awk -F: 'BEGIN{OFS=":"}{$2="*K*" ; print}' /etc/passwd
no biggie...I actually did "sed s/:x:/:*K*:/g passwd "....gotta love regex....The problem I was thinking was more moving this out to all our machines...we seem to have a growing number of linux machines around here ;-) (thankfully) Whats your thoughts on this difference? Should we ask Cristian Gafton? Or is this something we can just drop and accept as just a difference? Thanks, Erik Yes, please bounce this one off of Christian. I'm really not sure whether or not disabling this behavior is desirable. The pam-0.72-24 package will add a "broken_shadow" option to the pam_unix account module which will force pam_unix to ignore errors reading user shadow information. I have hit a similar issue syncing a passwd file set between a mixed RH 6.2 and 7.1 series .. this update did not resolve the issue at the 7.1 host ... testing |