Milan Jurik wrote: > Hi, > > linking collision between Solaris libldap and your/firefox libldap? > > See sunsolve for bug 6539516. There are patches released for it.
I don't think this is due to a linking error. There's no crash here. /etc/ssl/certs is a directory that is evidently used by a certain LDAP SDK that relies on OpenSSL. There is much documentation floating around on the web that clearly documents this as part of OpenSSL. It documents that OpenSSL uses /etc/ssl/* directories as the store of trusted CA certs. The use of this directory is also suggested in ldap.conf. What's surprising to me is that evidently there exists some implementation of ldap that tries to use this directory for both NSS and OpenSSL. Far from being "the system SSL certificate store" (as Mr. Mayer called it), /etc/ssl/certs is merely one LDAP library's idea of the location for the cert store for OpenSSL. I'd really like to know what implementation of LDAP does that. I didn't know there was an LDAP library that tries to use either or both of NSS and OpenSSL. (Mark, if you know the history of this and can shed any light on it, I'd be obliged to learn it.) In my mind, the real mystery continues to be this question: why is LDAP (*ANY* LDAP library) getting called during Firefox startup? The folks in bug 443408 believe that Firefox itself makes no direct calls to LDAP code. So, some function being called by Firefox is calling LDAP, unbeknown to and unexpected by Firefox, and that LDAP code is initializing NSS before Firefox itself does so. Today, One of my fellow NSS developers, Julien Pierre, came up with an interesting hypothesis. It seems that it is possible to configure Solaris to use LDAP for hostname-to-IP-Address name resolution queries (which might otherwise be called DNS queries, except that LDAP is being used in place of DNS) through Solaris's "Name Services Switch" (the *other* nss in Solaris - Yes, Solaris has two completely different things both known as nss). The Name Service Switch can be configured to use LDAP in a shared library named nss-ldap.so (that's Name-Service-Switch-LDAP), and that nss-ldap library uses the other NSS (Network Security Services, the crypto NSS) to do the SSL for LDAP-over-SSL (LDAPS). When Solaris is configured to use nss-ldap and ldap.conf says to use ldap over ssl, then when the first host name lookup is done by the browser (and browsers do A LOT of those) the nss-ldap code fires up LDAP, which initializes NSS (the crypto NSS) and points it to /etc/ssl/certs to find the cert DBs. Then later, when the browser tries to visit the first https URL, and tries to initialize NSS crypto for itself, it finds that NSS is already initialized, and so the second initialization is skipped, and NSS continues to use the DBs in /etc/ssl/certs. That is my current working hypothesis about this issue, until such time as it is proven or disproved. A second fallback hypothesis, that I might try if the first one is disproved, is that some other function, (other than a host name lookup, such as perhaps a call to getpwent or getpwnam) is similarly invoking LDAP in the browser process. I'd really like to get a stack trace of that first call to open an NSS DB file, to find out exactly how this happens. One more note, about why this happens in S10 but not in S8. It seems that before S10, Solaris's ldap libraries had their own complete private *OLD* copy of NSS statically linked into the ldap shared library. When LDAP initialized NSS, it was initializing its own private copy, not the browser's copy (which is in a shared library), so no conflict with the browser's copy occurred. Assuming that either of those hypotheses proves correct, IMO, going back to two complete copies of NSS in a single process's address space is NOT the preferred solution. I have at least a couple ideas about how to solve this; One short term, one longer term (bigger fix). Short term: The browser can attempt to shut down NSS before it attempts to initialize NSS. If NSS has been initialized by LDAP, this would shut down the NSS DBs in the directories where LDAP uses them, and would then begin to use the user's DBs in the user's directory. (And, by the way, Only God Knows what's happening to those poor DB files if multiple users are running browsers at the same time, all holding those DBs open simultaneously!) Longer term: Move the nss-LDAP client code out of user processes into a daemon process (call it the local LDAP proxy, for grins). Let that daemon process initialize its own copy of NSS, and let the user processes talk to the local LDAP proxy using some RPC protocol rather than using LDAP. (I will now don asbestos clothing and duck while awaiting reactions. :) /Nelson _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
