[rhelv6-list] getent weirdness (was: nscd weirdness) - SOLVED (not so much)

Thu Dec 23 16:42:17 UTC 2010

Just as a follow-up for future list readers, I thought I would post a
summary of the case I opened with Redhat on this.

The response essentially boiled down to:

Regardless of the fact that other passwd backends (files, NIS, etc)
expose the password hash with getent (regardless of calling user), they
don't see it as an issue that the backend for LDAP masks the password
hash with '*'. The logic is that the hash is not used in pam_ldap
authentication (an LDAP bind with password is).

To the point that nslcd specifically DOES expose the hash when the user
is root, but since nscd runs as non-root the root user can not see it
either, was that you either a) don't run nscd or b) don't query a
specific user - instead use enumeration since nscd doesn't handle
enumeration. Rather than run ' getent passwd oracle' run 'getent passwd
| grep ^oracle:'.

I personally still think this crap - getent should have consistent
behavior regardless of the backend... but I am tired of fighting this
battle.

Thanks,

Kevin

From: rhelv6-list-bounces at redhat.com
[mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Collins, Kevin
[BEELINE]
Sent: Thursday, December 09, 2010 11:23 AM
To: rhelv6-list at redhat.com
Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness)

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: rhelv6-list-bounces at redhat.com
[mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Collins, Kevin
[BEELINE]
Sent: Wednesday, December 08, 2010 4:05 PM
To: rhelv6-list at redhat.com
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: rhelv6-list-bounces at redhat.com
[mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Collins, Kevin
[BEELINE]
Sent: Wednesday, December 08, 2010 11:18 AM
To: rhelv6-list at redhat.com
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: rhelv6-list-bounces at redhat.com
[mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Collins, Kevin
[BEELINE]
Sent: Monday, December 06, 2010 10:06 AM
To: rhelv6-list at redhat.com
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20101223/44a62ab1/attachment.htm>