Bug 174064 - Root login fails with ldap in nsswitch.conf and newtork cable plugged out
Root login fails with ldap in nsswitch.conf and newtork cable plugged out
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
:
: 174100 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-24 03:14 EST by Umasankar
Modified: 2015-01-07 19:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-28 13:14:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Umasankar 2005-11-24 03:14:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Description of problem:
When we use ldap for passwd, shadow, group lookup in /etc/nsswitch.conf, the root user login to the virtual console fails with the network cable plugged out. 

--------
/etc/pam.d/system-auth :

auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok audit debug
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow audit
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow audit
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so audit
-----------

-----------
/etc/ldap.conf :
........
timelimit 60
bind_timelimit 60
idle_timelimit 3600
............
nss_base_passwd ou=People,dc=ip-soft,dc=net?sub
nss_base_shadow ou=People,dc=ip-soft,dc=net?sub
nss_base_group  ou=Group,dc=ip-soft,dc=net?sub
..........
------------

------------
/etc/nsswitch.conf :
........
passwd:     files ldap
shadow:     files ldap
group:      files ldap
........
------------

But surprisingly the login is successful when I remove ldap only for 'group' entry in /etc/nsswitch.conf (i.e. with 'group: files' only passwd, shadow still set to use ldap).

Ideally, ldap look up should not be done for local users. But I find that even under normal conditions, ldap lookup is done for local users - I confirmed this by snooping the network packets with ethereal. Even if it is so, with the network cable pulled out, at least nss_ldap should time out after 60 seconds (as per ldap.conf) and the login should succeed. I reduced the timelimit to even 1 and still it failed.

OS level="Red Hat Enterprise Linux ES release 4 (Nahant)"


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

How reproducible:
Always

Steps to Reproduce:
1. Use ldap for passwd, group, shadow in /etc/nsswitch.conf
2. Pull out the network cable
3. Login as root through the virtual console
  

Actual Results:  Get an error message that 'login timedout after 60 seconds' and the prompt returns to "login:"

Expected Results:  Root should have logged in successfully.

Additional info:
Comment 1 Nalin Dahyabhai 2005-11-28 13:14:11 EST
This is expected behavior -- group membership is additive, so it's valid for
users whose passwd entries originate from local files to be listed as members of
groups which are defined on the network, and vice-versa.

I think you're getting multiple requests to the directory server here, so even
with the timeouts you've defined, you're still exceeding the 60 second limit
because the time limits apply to each request.  (I expect that a login via a
graphical desktop or sshd isn't going to hit a timeout.)  Try a lower time
limit, which I think will improve the situation.

Closing as won't-fix because the additive-groups behavior isn't intended to change.
Comment 2 Nalin Dahyabhai 2005-11-28 13:15:12 EST
*** Bug 174100 has been marked as a duplicate of this bug. ***

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