rra@stanford.edu wrote:

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 hostname resolution.