Bug 434842
Summary: | local logins fail when network connection lost | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Corporate UNIX <corporateunix> |
Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 4.6 | CC: | dossy, jplans, jsafrane |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-20 13:28:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Corporate UNIX
2008-02-25 19:46:21 UTC
I forgot to mention that I noticed some other odd behavior during my simulated network failure testing. I use iptables to block only the outgoing connections to the LDAP server, so I decided to see what would happen if I attempted to login as root from another location on the network. I enabled root logins in sshd_config, restarted sshd, and tried logging in. After typing the ssh command, it pauses for about 60 seconds, then prompts for the password. After entering root's password, I am immediately greeted with the "Last login" information, after which it pauses for another 60 seconds. Then I am finally presented the root shell. /etc/pam.d/sshd is configured as default: auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_loginuid.so It does not seem to be openldap problem, glibc should not try to contact ldap server if it can find all root account information locally. As a workaround you can tweak the ldap timeouts in /etc/ldap.conf (timelimit and bind_timelimit options). Except that glibc doesn't try to contact ldap server at all, it is the nss_ldap plugin that does that. During login etc. initgroups or getgrouplist are called. And these functions really have to look through all groups to see what groups the user (in your case root) belongs to. Wait, so not being able to login on to console as root during a network outage is not a bug? How can that be considered expected behavior? If nsswitch.conf is configured to go to files then ldap, why is it attempting to look at ldap for groups? The default behavior is supposed to be success=return - Are you suggesting that it is expecting to find that local users are also part of ldap groups? Regardless, this issue should remain open and be considered a bug. Default, expected behavior should NOT lock you completely out of the system during an LDAP or network failure. That's akin to programming my car to refuse to unlock when it's hailing outside - it won't happen very often, but it will happen. Also take into consideration the serious ramifications if a malicious person were to deliberately target someone's LDAP servers, knowing the default behavior will lock them out of ALL of their LDAP connected servers. Adding the following to ldap.conf did indeed fix this problem: bind_timelimit 15 timelimit 15 It actually took about 30 seconds to timeout because of the nss_reconnect values I stated earlier. Perhaps the default login timeout should be increased, or the default values for bind_timelimit, timelimit and nss_reconnect should be changed to prevent a console login from timing out before the LDAP query? Granted, using nscd also fixes this problem (short term), but I shouldn't have to rely on it. I stand by my assertion that it's ludicrous to have a default design that locks root completely out of the system because of a little network issue. A determined hacker could use this little bug to their advantage. They could have their way with your most critical server while you were busy troubleshooting LDAP issues. Or, a malicious user could DDOS your LDAP servers, locking out everyone on every LDAP connected server in your network. another hint: try to add to your /etc/ldap.conf: nss_initgroups_ignoreusers root As result, nss_ldap will not ask LDAP server for list of root's groups. That would be the valid solution for this, however a concern would be Bug 429101 where a lock is not cleared up if the option is used.. causing dbus to lockup during the boot sequence. This should be, however, fixed in 4.7's nss_ldap package. Jose I thought the nss_reconnect options were only implemented in nss_ldap v2.41 and newer. Were they backported to RHEL 4 ? http://www.liquidx.net/blog/2006/04/03/nss_ldap-undocumented-nss_reconnect_tries/ 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. |