Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 176209 - nss_ldap prevents even root from logging in if network is down
nss_ldap prevents even root from logging in if network is down
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
BaseOS QE Security Team
: FutureFeature
: 176217 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-12-20 03:59 EST by bugreports2005
Modified: 2012-06-20 12:11 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 12:11:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description bugreports2005 2005-12-20 03:59:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051001 Firefox/1.0.7

Description of problem:
This is not a bug as such, but without extra functionality or an acceptable workaround it will force us to use flat files instead of LDAP for group lookup. We plan to use LDAP for the other user tables, and pam_ldap for authentication, so having to settle for files with group would be very inconvenient.

When a user logs in, the system needs to find out which groups he belongs to. In /etc/nsswitch.conf we have:

group: files ldap

Now, a user may belong in groups in both flat files and ldap, so nss cannot ignore ldap even if there are matches in the group file. The only account in our flat files that can log in is root. While root does not belong to any groups in LDAP, nor is there need for it, LDAP still gets checked for groups when the root user logs in.

If the network happens to be down and the ldap server unreachable, nss_ldap will spend enough time waiting and retrying for login itself to timeout. As a consequence, even root cannot login.

It has been suggested to me that by significantly lowering bind_timelimit and timelimit in /etc/ldap.conf as well as #define LDAP_NSS_TRIES in nss-ldap.h, one could bring the waiting time so low that login will not time out.

This would, however, have broad consequences for working around a very specific problem. The root user has little need to belong to groups in LDAP, so the whole problem could be avoided by avoiding the lookup. I suspect the same may hold true for most system accounts, although root is the only one we want to log in with.

What I would like to see would be an extra option in /etc/ldap.conf to skip all LDAP lookups relating to certain users. It could for example take the form of a blacklist or an option similar to pam_min_uid. Or even better, a blacklist read from /etc/passwd with the assumption that all users found there are to be truly local to the system.

I would be happy to hear other suggestions, in case this is a problem that is generally solved some other way.

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

How reproducible:

Steps to Reproduce:
1. setup nss to use "files ldap" for groups
2. make sure the root account is local, and disconnect network
3. with ldap server now unreachable, try to login as root

Actual Results:  After 60 seconds, login times out.

Expected Results:  root gets logged in.

Additional info:
Comment 1 bugreports2005 2005-12-20 06:17:09 EST
*** Bug 176217 has been marked as a duplicate of this bug. ***
Comment 3 Jiri Pallich 2012-06-20 12:11:42 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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