Re: [nssldap] nss_ldap on SLES 10

[Ralf Haferkamp <rhafer [at] suse.de>]

On Tuesday 30 January 2007 18:16, Iain Morgan wrote:
[..]
>
> > You also might wanna check the LDAP Server logs. Probably you can see as
> > what user (rootbinddn/binddn/anonymous) nss_ldap is trying to
> > authenticate against the LDAP server.
>
> Yeah, I forgot to include that in my original post. With SLES 10, it is
> attempting to bind anonymously. The only exception to this is when I run
> 'getent shadow' as root. In that case it uses rootbinddn.
It seems you hit a bug in nss_ldap. I was able to recreate you problem here. 
Sometimes (especially when used through nscd) it seems that nss_ldap is not 
correctly initialized. Even if rootbinddn is set in the config file. The 
option is not set in nss_ldap's internal data structures.

I have however not find out what causes this problem :(

> > > Whereas the same configuration under
> > > SLES 9 works as you would expect for both 'getent shadow' and 'getent
> > > passwd'.
> > >
> > > I'm assuming the issue is that nscd 2.4 drops privileges for all
> > > queries except getsp*().
> >
> > Did you configure to run as a separate user?q If not, I think it does not
> > drop privileges anywhere. But I must admit that my nscd-knowledge is
> > pretty limited.
>
> No. The daemon itself appears to be running as root, at least according
> to ps. But since rootbinddn is being ignored for most queries I'm
> assuming that nscd or nss_ldap is dropping privileges. And I haven't
> seen any indication of that in the nss_ldap code.
>
> > Additionally note that neither "getent passwd" (without any user name
> > supplied) nor "getent shadow" and the getsp*() calls make use of nscd.
>
> They appear to under SLES 9.
No. The enumeration calls like getpwent, getgrent and so one where never using 
nscd.

> I should also note that I was abbreviating 
> when I referred to 'getent passwd' and 'getent shadow' in my original
> post. I was implicitly meaning 'getent passwd <username>' and 'getent
> shadow <username>'.
Ok, thats different, when supplied with the username, those calls don't use 
the get*ent() functions (IIRC).

-- 
Ralf Haferkamp
SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg
T: +49-911-74053-0
F: +49-911-74053575 - Ralf.Haferkamp@suse.com