Bug 14730 - pam_unix.so must have shadow file to pass account component for non local users
pam_unix.so must have shadow file to pass account component for non local users
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: pam (Show other bugs)
1.0
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-27 10:40 EDT by Erik J Burckart
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-28 14:19:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Erik J Burckart 2000-07-27 10:40:33 EDT
This was only tested with our afs pam module in Red Hat Linux release 6.9.2
(Winston Beta 3)

I installed 6.9.2 and did not use shadow or md5 encryption for passwords. 
Our afs pam module works in a way that we only add it to the auth component
of pam right before pam_unix or pam_pwdb as sufficient.  With pam_pwdb.so,
pam would/will authenticate users through our afs pam module just fine. 
However, the pam_unix.so module now included in 6.9.2 will not authenticate
users in the account component.  It gives an error: 

	Red Hat Linux release 6.9.2 (Winston Beta 3)
	Kernel 2.2.16-8 on an i586
	login: ejburcka
	AFS Password: 

	User account has expired

Now, local users can still login fine...but the remote ones cannot.  But,
if I add a line like "ejburcka:!!:9281:0:99999:7:::" in /etc/shadow (which
didn't even exist) I am authenticated just fine.

This means that external users cannot login without either shadow passwords
enable or a shadow password file with expiration information.

This seems like a bug, but I apologize if it was intentional.  It
definitely acts different than pam_pwdb does.  If I replace pam_unix.so
with pam_pwdb.so in the account component, all works fine.

Thanks for looking at this.

-Erik
Comment 1 Nalin Dahyabhai 2000-07-27 15:35:19 EDT
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.
Comment 2 Erik J Burckart 2000-07-27 16:11:21 EDT
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
Comment 3 Nalin Dahyabhai 2000-07-27 16:17:19 EDT
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?
Comment 4 Erik J Burckart 2000-07-27 16:23:57 EDT
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.)
Comment 5 Nalin Dahyabhai 2000-07-27 19:16:50 EDT
How about this awk invocation?
awk -F: 'BEGIN{OFS=":"}{$2="*K*" ; print}' /etc/passwd
Comment 6 Erik J Burckart 2000-07-28 07:44:33 EDT
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
Comment 7 Nalin Dahyabhai 2000-07-28 14:18:59 EDT
Yes, please bounce this one off of Christian.  I'm really not sure whether
or not disabling this behavior is desirable.
Comment 8 Nalin Dahyabhai 2000-07-31 17:14:09 EDT
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.
Comment 9 R P Herrold 2001-09-10 16:43:31 EDT
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

Note You need to log in before you can comment on or make changes to this bug.