I have found the root (no pun intended!) of this problem in the /usr/share/doc/nss-pam-ldapd-0.7.5/NEWS file included in the RPM:
changes from 0.6.11 to 0.7.0 ---------------------------- ... ... * password hashes are no longer returned to non-root users (based on a patch by Alexander V. Chernikov) ... So, I can sort of see the point of this, but I think that this daemon should return what the calling user has access to. If the password hash is not protected, it can be via ACLs from the LDAP server or it can be mapped to a different value. At the very least, there should be an option to allow that behavior. Deciding to just say "no" seems wrong... Where this becomes interesting is the case where you run nslcd *and* nscd: since nscd runs as user 'nscd' (not root), root will never get the password hash either since the nss calls are routed via nscd. Not sure if anyone else cares since I have seen no replies, but I figured it's worth documenting. I will probably open a support case just to see what the response is. Thanks, Kevin From: [email protected] [mailto:[email protected]] On Behalf Of Collins, Kevin [BEELINE] Sent: Wednesday, December 08, 2010 4:05 PM To: [email protected] Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness) I have narrowed this down to nslcd by using strace: [pid 7141] read(12, "\202\1\35\4\"uid=oracle,ou=People,dc=afis,dc=sr0\201\3660\17\4\3uid1\10 \4\6oracle0\24\4\2cn1\16\4\fOracle Owner0+\4\vobjectClass1\34\4\7account\4\fposixAccount\4\3top0&\4\fuserPa ssword1\26\4\24{crypt}No_Login*****0\33\4\nloginShell1\r\4\v/usr/bin/sh0 \22\4\tuidNumber1\5\4\0032000\22\4\tgidNumber1\5\4\0032000\32\4\rhomeDir ectory1\t\4\7/oracle0\27\4\5gecos1\16\4\fOracle Owner", 288) = 288 [pid 7141] select(1024, NULL, [6], NULL, {0, 0}) = 1 (out [6], left {0, 0}) [pid 7141] sendto(6, "\1\0\0\0\351\3\0\0\0\0\0\0\6\0\0\0oracle\1\0\0\0*\310\0\0\0\310\0\0\0\f \0\0\0Oracle Owner\7\0\0\0/oracle\v\0", 64, MSG_NOSIGNAL, NULL, 0) = 64 Notice the read() gets back the actual password data "{crypt}No_Login*****" but the sendto() is sending "*"? Now to research... Kevin From: [email protected] [mailto:[email protected]] On Behalf Of Collins, Kevin [BEELINE] Sent: Wednesday, December 08, 2010 11:18 AM To: [email protected] Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness) After further investigation, this seems to be an issue with getent. If the effective UID is not 0, it returns '*' as the passwd hash. This is not the behavior exhibited in previous versions, and explains why I see the issue from root when nscd is running - nscd does a setuid to the user 'nscd'. I checked this on another RHEL6 server that is resolving via NIS and it does *not* exhibit this behavior, so it has some relationship to LDAP. But, I can run ldapsearch and get back the passwd hash as any user (our LDAP allows anonymous read-only to all attributes). Now my suspicion is that this is caused by nss_ldap, which is different in RHEL6 since this is now part of nss-pam-ldapd. Any thoughts? Thanks, Kevin From: [email protected] [mailto:[email protected]] On Behalf Of Collins, Kevin [BEELINE] Sent: Monday, December 06, 2010 10:06 AM To: [email protected] Subject: [rhelv6-list] nscd weirdness I am seeing different output in the password field of the passwd output from 'getent' when I have nscd runnng versus when I don't: # ps -ef | grep -E 'nscd|nslcd' nscd 18126 1 0 09:42 ? 00:00:00 /usr/sbin/nscd nslcd 18206 1 0 09:44 ? 00:00:00 /usr/sbin/nslcd # getent passwd oracle oracle:*:200:200:Oracle Owner:/oracle:/usr/bin/sh # service nscd stop Stopping nscd: [ OK ] # getent passwd oracle oracle:No_Login*****:200:200:Oracle Owner:/oracle:/usr/bin/sh # nscd -i passwd # getent passwd oracle oracle:No_Login*****:200:200:Oracle Owner:/oracle:/usr/bin/sh # service nscd start Starting nscd: [ OK ] # getent passwd oracle oracle:*:200:200:Oracle Owner:/oracle:/usr/bin/sh As you can see, I have tried flushing the passwd cache and restarting nscd with no luck. The backend in this case is LDAP - the problem does not appear when I am getting information from an ID in /etc/passwd. Any ideas? Thanks, Kevin
_______________________________________________ rhelv6-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv6-list
