Red Hat Bugzilla – Bug 176217
nss_ldap prevents even root from logging in if network is down
Last modified: 2015-01-07 19:11:23 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):
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.
*** This bug has been marked as a duplicate of 176209 ***