[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: libldap and _r-functions

Luke Howard wrote:

Simply put, the NSS (and PAM) architecture is problematic in
that all kinds of code which conflicts with the program can
be linked in at run time. The program has little protection

from the module and the module has little protection from the

program. I don't view this as a OpenLDAP-specific problem,
as there simply is little we can do to prevent program/module
conflicts at the library level. (Not to say that we couldn't
use separate symbols in libldap and libldap_r, but more to
say that use of separate symbols won't do all that much to
prevent program/module conflicts that are inherit in the
NSS (and PAM) architecture).

Probably the only way to avoid conflicts (unfortunately) is to
statically link libldap{_r} into nss_ldap, and ensure that its
symbols are not exported.

Yes, this is what Symas does in our CNS packages; it's the only approach that works reliably on Solaris which has otherwise unavoidable conflicts with the Sun native LDAP libraries. Strangely enough, while we've been doing our Solaris builds this way for a couple of years, we never ran into issues on Linux.

Of course, if we had have adopted a client/server architecture
for nss_ldap this could have been avoided...

Chicken and egg. You need some form of library to talk to the NSS server then. nscd is actually a good thing here, but unfortunately it is bypassed by some of the NSS calls.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support