[Date Prev][Date Next]
Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch
> We'll talk this over and see if there's a way that we can either move from
> nss-ldap or try to get it out of the places where it causes problems,
> although that's going to be really rough going as you can probably
> imagine. libnss-ldap has over 2,800 installations that report popcon
> statistics, which means a *lot* of people are using it.
> Thinking out-loud here a bit (because I really want to solve this problem
> in the long run in a way that you can support), libnss-ldap and slapd on
> the same system are instant death unless everything uses libldap_r. If we
> have slapd conflict with libnss-ldap and then have only slapd use
> libldap_r (and make people use libnss-ldapd on systems that are also
> running slapd), we may solve a fair chunk of the problem. The other place
> where libldap is pulled in is via PAM, but slapd itself should never need
> to call into PAM (even indirectly).
You might consider suggesting to PADL that they contribute pam/nss_ldap to the
OpenLDAP Project, if you want us to take an active role in solving this. Until
then, the discussion just doesn't belong here on the OpenLDAP ITS. I'll note
that I've described the solution Symas uses in our commercial distribution of
pam/nss-ldap on the pam/nss-ldap mailing lists in the past. Our package has
none of these issues.
Hint: since dynamic linker dependencies are causing the conflict, the solution
is not to rely on the dynamic linker. In this particular case, using the
dynamic linker introduces a security vulnerability anyway.
> If any slapd backends load dynamic libraries that in turn load libldap,
> the world may also explode, but this should only affect back-perl, which
> isn't working right now anyway due to the libtool RTLD_GLOBAL issues.
>> The other obvious step in this situation is never to use LDAP for
>> hostname resolution. ("Doctor, it hurts when I do this." - "Don't do
>> that.") LDAP is a much heavier weight protocol than DNS; as such it's
>> simply the wrong tool for the job. (Note - I like using DNS servers
>> backed by LDAP, but that's a completely different situation.)
> Okay. I can at least pass that along to the user.
Or patch nss_ldap to simply return a failure whenever it's invoked for
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/