Bug 14730 - pam_unix.so must have shadow file to pass account component for non local users
Summary: pam_unix.so must have shadow file to pass account component for non local users
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: pam   
(Show other bugs)
Version: 1.0
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-27 14:40 UTC by Erik J Burckart
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-28 18:19:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Erik J Burckart 2000-07-27 14:40:33 UTC
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.


Comment 1 Nalin Dahyabhai 2000-07-27 19:35:19 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.

Comment 2 Erik J Burckart 2000-07-27 20:11:21 UTC
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 20:17:19 UTC
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
is causing the behavior you're seeing?

Comment 4 Erik J Burckart 2000-07-27 20:23:57 UTC
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 23:16:50 UTC
How about this awk invocation?
awk -F: 'BEGIN{OFS=":"}{$2="*K*" ; print}' /etc/passwd

Comment 6 Erik J Burckart 2000-07-28 11:44:33 UTC
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 ;-)

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 18:18:59 UTC
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 21:14:09 UTC
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

Comment 9 R P Herrold 2001-09-10 20:43:31 UTC
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.