[rhelv6-list] getent weirdness (was: nscd weirdness)

[Collins, Kevin [BEELINE]]

Did you miss the part where I said this impacts root?

And regardless of why I want (or don't want) to do this, it should be my
choice. I may have scripts that process the output of getent to check
for expired users, etc that rely on getting the password hash. In NIS or
a non-shadow environment, this is the case anyway.

We primarily use SSO with kerberos (from AD), so our password hashes do
not contain a password in (our) LDAP (not AD)... but they do contain
strings that are used to denote the state of the user.

Kevin

-----Original Message-----
From: Kinzel, David [mailto:David.Kinzel at encana.com] 
Sent: Thursday, December 09, 2010 1:55 PM
To: Collins, Kevin [BEELINE]; rhelv6-list at redhat.com
Subject: RE: [rhelv6-list] getent weirdness (was: nscd weirdness)

What seems wrong is wanting the password hash to be given to regular
users.
 
Why?

________________________________

	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 12:23 PM
	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

	 
	Kevin


This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use
of the intended recipient only.  Any review, retransmission or
dissemination of this information by anyone other than the intended
recipient is prohibited.  If you receive this email in error, please
contact the sender and delete this communication and any copies
immediately.  Thank you.
http://www.encana.com