Luke Howard wrote:
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.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.
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.Of course, if we had have adopted a client/server architecture for nss_ldap this could have been avoided...
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support