Bug 55193 - PAM config for network auth blocks all *local* logins when network is down
PAM config for network auth blocks all *local* logins when network is down
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
:
: 53796 63631 77575 100504 103461 112212 118239 121944 122700 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-26 16:51 EDT by Kevin Becker
Modified: 2009-02-17 00:20 EST (History)
43 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-15 03:29:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch which solves this - see the README.ldap_required file it creates! (14.37 KB, patch)
2002-04-01 09:27 EST, Iustin Pop
no flags Details | Diff
This patch adds authinfo_unavail=ignore to LOGIC_IGNORE_UNKNOWN in authinfo.c. Should work for every network-based authentication configured with authconfig. (692 bytes, patch)
2002-10-24 17:07 EDT, Andreas Rogge
no flags Details | Diff

  None (edit)
Description Red Hat Bugzilla 2001-10-26 16:51:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901

Description of problem:
I configured my system to use LDAP authentication during install and was
unable to logon to the machine using the local root account.  I booted in
single user mode and ran authconfig (still choosing to allow LDAP) and
still could not logon. The file /etc/pam.d/system-auth had the line
"account required /lib/security/pam_ldap.so"  I changed this to "account
sufficient /lib/security/pam_ldap.so" and now it is working as desired.  If
this configuration is intentional, I would request authconfig be modified
to allow a choice between required and sufficient, otherwise it is not
possible to logon to the machine without LDAP connectivity.  I had, for
instance, chosen to use TLS but our LDAP directory seemingly doesn't
support it, so I was unable to logon in any way (other than single user mode).

Version-Release number of selected component (if applicable):
authconfig-4.1.19-1


How reproducible:
Didn't try

Steps to Reproduce:
1.run /usr/sbin/authconfig
2.choose "Use LDAP"
3.enter your LDAP server and base DN
4.reboot and attempt to logon to machine with an account in /etc/passwd but
not in the LDAP directory (such as root)
	

Actual Results:  I was unable to logon to machine

Expected Results:  I should have been able to logon as root, using the
local account information in /etc/passwd & /etc/shadow

Additional info:
Comment 1 Red Hat Bugzilla 2001-10-30 09:03:20 EST
I confirm this problem. The old behaviour was to still allow a fallback to the
/etc/passwd /etc/shadow when the ldap server is down. Now it falls back to those
files only if the ldap server is running, not if it cannot be contacted.

Here's what the logs give :
Oct 30 15:01:37 localhost login: pam_ldap: ldap_simple_bind Can't contact LDAP
server
Oct 30 15:01:37 localhost login: Error in service module



Comment 2 Red Hat Bugzilla 2002-03-20 05:00:04 EST
I confirm this as well.  If you do not set account to sufficient under account,
the system will not be accessible when the ldap server is down.  This has given
me two headaches thus far.  ;)
Comment 3 Red Hat Bugzilla 2002-04-01 09:27:33 EST
Created attachment 51645 [details]
Patch which solves this - see the README.ldap_required file it creates!
Comment 4 Red Hat Bugzilla 2002-05-23 17:12:33 EDT
Confirmed for me too.  Though for me, authconfig creates "account sufficient" 
for pam_ldap.so after "account required" for pam_unix.so.  Modifying the auth 
commands doesn't work until I reverse the account commands.
Comment 5 Red Hat Bugzilla 2002-05-28 16:44:31 EDT
I've confirmed this behavior in 7.2, 7.3, and the Advanced Server beta.
It looks like they changed the system-auth a bit in 7.3, as it now contains
this line:

account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/pam_ldap.so

I assume this was an attempt at fixing this particular issue, but yet again, if
the LDAP server is down, root cannot log in at the console.
Comment 6 Red Hat Bugzilla 2002-10-16 07:14:19 EDT
Same problem here with RHL 8.0.
I've resolved with this line:

account [... authinfo_unavail=ignore ...]  /lib/security/pam_ldap.so
Comment 7 Red Hat Bugzilla 2002-10-24 17:07:06 EDT
Created attachment 81986 [details]
This patch adds authinfo_unavail=ignore to LOGIC_IGNORE_UNKNOWN in authinfo.c. Should work for every network-based authentication configured with authconfig.
Comment 8 Red Hat Bugzilla 2003-04-24 14:59:26 EDT
Confirmed that this issue still exists in Red Hat 9, authconfig-4.3.4.
Comment 9 Red Hat Bugzilla 2003-06-09 19:42:07 EDT
Can we please, please, please get an updated authconfig package?  I can confirm
that this problem affects all of Red Hat Linux releases 7.3, 8.0, and 9.

This is compounded, I believe, by nscd, which will cache DNS failures for a very
long time.  If there is a minor network outage, which causes the LDAP server to
become unavailable, you will apparently *never* be able to log in as any user
again.  You must reboot the box.  This situation sucks.  A lot.

I can also confirm that the patch attached to this bug on 2002/10/24 resolves
the issue.

Nalin~ Is there anything we can do to help you resolve this issue?  Do you need
a test case which will reliably reproduce this problem?
Comment 10 Red Hat Bugzilla 2003-07-10 17:24:22 EDT
I'm not sure this is the right way to patch this problem.... instead of adding
"authinfo_unavail=ignore" to the account definition for pam_ldap, you can
instead change the preceding line for pam_unix from:

account required /lib/security/$ISA/pam_unix.so

to:

account sufficient /lib/security/$ISA/pam_unix.so

which seems more in keeping with the intentions of the PAM designers.  I have
not emailed Andrew about this, though.

Regardless, the pam options for ldap in system-auth clearly need to be reworked,
and the configuration used by authconfig in Red Hat 7.2 - 9.0 is b0rked and is
generating lots of bugzilla traffic because pam affects so many other things.
Comment 11 Red Hat Bugzilla 2003-07-25 08:42:51 EDT
*** Bug 77575 has been marked as a duplicate of this bug. ***
Comment 12 Red Hat Bugzilla 2003-08-19 15:49:36 EDT
For the record, this ain't just an LDAP problem. Happens with kerberos too.

I asssume it's "required" instead of "sufficient" to prevent timing-based
information-gathering attacks, so the authinfo_unavail=ignore solution might be
best.
Comment 13 Red Hat Bugzilla 2003-09-26 19:19:11 EDT
Does anyone have an RPM package with the authinfo_unavail=ignore fix?  We have a
lot of machines authenticating off of LDAP with rh9 and I'd like not to roll out
a patch machine-by-machine -- would much prefer to have an rpm on our
kickstart/update server.
-alan
Comment 14 Red Hat Bugzilla 2003-09-27 18:23:54 EDT
Sure, check here:

http://phantom.dragonsdawn.net/~gordon/authconfig/

There's binary and source packages, but I recommend (for your own security) that
you just grab the spec that's appropriate for your system, and the patch. 
Compare the spec to the one in the src.rpm available from Red Hat, and then use
it to build your own binaries.
Comment 15 Red Hat Bugzilla 2003-12-03 17:49:02 EST
There are three things I've done to ensure my local users can always
log in:

1) the authinfo_unavail=ignore solution
2) adding a line "account sufficient /lib/security/pam_localuser.so"
3) Make sure your ldap servers are listed in /etc/hosts.

#3 is very important, because if the DNS servers are down, or you're
disconnected from your network, the login will timeout on the DNS
lookup, and your login will fail, even if you are root.
Comment 16 Red Hat Bugzilla 2004-03-02 15:41:44 EST
Fifty-two months and three redhat major releases after this bug was
opened, I can confirm it's still present in flagship RHEL 3 U1. The
cause is known, the simple half-line patch is there, now perhaps
someone can incorporate it in the distribution so we can waste our
time on the next annoyance instead.

Since 9 is almost EOL an RHEL is "actively supported" <cough>, the bug
should be moved to RHEL.
 
Comment 17 Red Hat Bugzilla 2004-03-03 11:48:55 EST
Don't hold your breath, Zenon!
I don't think Nalin reads Bugzilla.
He's very talented but he's either overloaded with work or his 
priorities are screwed.
Comment 18 Red Hat Bugzilla 2004-03-29 15:18:27 EST
I'd just like to confirm that this bug is still there in Fedora Core 1. I haven't checked 
the -test releases of FC2 (at time of writing FC2-test1 is the most recent version).

I've been carrying the fix for this (I use the autoinfo_unavail=ignore option) in my 
config files for years now (RH 7.3, 8.0, 9, AS 3, FC1), and I'd really like to drop it.
Comment 19 Red Hat Bugzilla 2004-03-29 15:32:15 EST
I can confirm that this is still a problem in FC2-test2. 

This is a very significant problem, as it prevents local root logins
for emergency problem solving when the network is down -- not cool at
all. And as mentioned above, it's not just LDAP -- Kerberos, too.


authinfo_unavail, not autoinfo, btw. :)
Comment 20 Red Hat Bugzilla 2004-03-29 15:37:23 EST
Indeed this is a real nasty of a bug... would appreciate seeing an 
official update for RH9, EL3 etc.
Comment 21 Red Hat Bugzilla 2004-03-29 15:39:23 EST
Suggest changing summary to:

"PAM config for network auth blocks all *local* logins when network is
down [has patch]"
Comment 22 Red Hat Bugzilla 2004-03-29 16:09:22 EST
The authinfo_unavail patch solves this problem, but the account
section of system-auth seems out of place relative to the others. 
Auth and passwd both mark the local and network authentication modules
as sufficient, and then place a required "deny" at the end of the
stack.  The same should work for the account stack.
Comment 23 Red Hat Bugzilla 2004-03-30 09:57:59 EST
*** Bug 112212 has been marked as a duplicate of this bug. ***
Comment 24 Red Hat Bugzilla 2004-03-30 10:07:34 EST
*** Bug 103461 has been marked as a duplicate of this bug. ***
Comment 25 Red Hat Bugzilla 2004-03-30 10:08:54 EST
*** Bug 118239 has been marked as a duplicate of this bug. ***
Comment 26 Red Hat Bugzilla 2004-03-30 11:02:23 EST
The authinfo_unavail fix did not work for me and I figured out why. I
had configured my ldap servers in the following way:
 host ldap1 ldap2
By using domain names rather than IPs, I guess that I'm getting a
different error code in pam_ldap, related to the name resolution failure.
What about using the solution described in bug 118239?
Comment 27 Red Hat Bugzilla 2004-04-02 11:06:54 EST
I just tried another approach. Instead of setting all those behaviors,
only set behaviors for default and success:

account [default=ignore success=ok] /lib/security/$ISA/pam_ldap.so

on my Test-System it looks allright, but I don't know whether this
breaks security or not.

Can anybody confirm that this is still safe? I', not sure about this.

Charles: Can you confirm this fixes the Bug for your scenario?
Matthew: Does this still prevent the "timing-based information
attacks" you mentioned earlier? I think it does, but I am not a
security expert.
Comment 28 Red Hat Bugzilla 2004-04-13 12:42:05 EDT
Re: comment #14

Following these three steps still keeps root locked out of a "Red Hat
Enterprise Linux AS release 3 (Taroon)" configured for LDAP
authentication if the network connection becomes unavailable. Either
login(1) times out before DNS does or we're still stuck in pam_ldap,
and since none of the above log at all, it's kind of hard to tell.
Comment 29 Red Hat Bugzilla 2004-04-13 13:36:19 EDT
It would appear that the culprit is not, in fact, pam_ldap.so, but
pam_unix.so, and as long as you touch it if the local host's network
connection goes down, you're screwed, because pam_unix.so calls
getpwname() which, in turn, calls LDAP, which is where we die.

See http://www.netsys.com/pamldap/2002/04/msg00026.html.
Comment 30 Red Hat Bugzilla 2004-04-20 17:58:04 EDT
We just lost our connection to our ldap servers and I had to manually 
reboot each of my file servers to single user mode in order to login 
as root. This seems like a huge bug to me. My manager just asked me 
why this bug has been outstanding for two and a half years on a 
product labelled "enterprise"? I don't have an answer for him.
Comment 31 Red Hat Bugzilla 2004-05-11 14:56:06 EDT
Confirming this bug still exists in Fedora Core 2 test3 and will 
probably still exist in Core 2 :-(. 
 
How do other distributions handle this? 
Comment 32 Red Hat Bugzilla 2004-05-12 01:13:56 EDT
Maybe Nalin no longer maintains this component? Re-assigning needed?
Comment 33 Red Hat Bugzilla 2004-05-12 01:47:52 EDT
In September 2002 I went to a AUUG conference and listened to a talk
"Polythene PAM ain't what she used to be". This problem was described
then. Nalin is mentioned in the paper.

http://meltin.net/people/martin/publications/polythenepam.pdf

I don't know if the workaround in the paper solves the problem.
Comment 34 Red Hat Bugzilla 2004-06-09 12:09:18 EDT
The workaround in the paper referenced in #32 works for me.  Mostly...

I still have the problem that if I kill the network, log in as root
(which works, thanks to the config above), and do an ls -la, it hangs.
 Apparently the ls can't get the uid/gid information.  If I kill nscd,
then I get raw numbers back as expected.  Maybe there is something I
can tweak in nscd.conf so that lookups fail faster?

Also, this bug MAY be fixed in FC2...  I have some FC2 machines here
(the rest are 90% Redhat9 with a few FC1) and they could log in as
root when ldap died....

Don't knw about the ls -la thing though...
Comment 35 Red Hat Bugzilla 2004-06-09 21:43:19 EDT
Note:

Authconfig from Fedora Core 2 has a partial fix -- the account section
begins with:

account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100

Which should cure the problem for system accounts. Personally,
pam_localuser seems like a better (more comprehensive and more
specific) choice, but it's possible that there's further implications
of that.
Comment 36 Red Hat Bugzilla 2004-06-10 11:22:27 EDT
Do not use pam_succeed_if as discussed above if you are using NIS
and nsswitch.conf in compat mode as logins for users in more than 8 
groups will fail.  See 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125653
Comment 40 Red Hat Bugzilla 2004-10-08 01:17:33 EDT
"Authconfig from Fedora Core 2 has a partial fix -- the account section
begins with:

account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100

Which should cure the problem for system accounts."

This does not fix the problem on FC3-Test2.  Root login attempt times
out in about 50 seconds.  
Comment 41 Red Hat Bugzilla 2004-10-08 02:17:56 EDT
"1) the authinfo_unavail=ignore solution
2) adding a line "account sufficient /lib/security/pam_localuser.so"
3) Make sure your ldap servers are listed in /etc/hosts."

The above works on FC3-Test2:

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100
account     [default=bad success=ok user_unknown=ignore
service_err=ignore authi
nfo_unavail=ignore ] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_permit.so
account     sufficient    /lib/security/$ISA/pam_localuser.so

ls is hanging for about a second when LDAP is unavailable.  :(
Comment 42 Red Hat Bugzilla 2004-10-15 03:29:02 EDT
This now works fine for system accounts (uid<100) when using current
authconfig and pam packages.
Enabling it for all local users is WONTFIX as it would be a security
problem.
Comment 43 Red Hat Bugzilla 2004-10-15 03:31:50 EDT
*** Bug 121944 has been marked as a duplicate of this bug. ***
Comment 44 Red Hat Bugzilla 2004-10-15 03:33:03 EDT
*** Bug 63631 has been marked as a duplicate of this bug. ***
Comment 45 Red Hat Bugzilla 2004-10-15 03:34:11 EDT
*** Bug 122700 has been marked as a duplicate of this bug. ***
Comment 46 Red Hat Bugzilla 2004-10-15 03:37:51 EDT
*** Bug 100504 has been marked as a duplicate of this bug. ***
Comment 47 Red Hat Bugzilla 2004-10-15 03:44:25 EDT
*** Bug 53796 has been marked as a duplicate of this bug. ***
Comment 48 Red Hat Bugzilla 2005-03-07 21:43:38 EST
These fixes do work, if /usr is mounted locally. We are running of a
nfs mounted /usr, the pam modules are linked to shared libraries in
/usr, so if the network is down not even root can login to the system.
This is an issue for me.

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