Hi Nelson, V st, 23. 07. 2008 v 06:27, Nelson Bolyard píše: > 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 >
Few notes. Yes, Solaris (and not only Solaris these days) has Name Service Switch, which allows to have different name service backends (not only files and DNS, but also NIS, NIS+, LDAP ...). In Solaris, there are two known LDAP backends, Native LDAP backend, depending on Mozilla libldap, and PADL/OpenLDAP backend. You are right, /etc/ssl/certs are OpenSSL/OpenLDAP specific, so Michael is using PADL as LDAP backend probably (btw. not supported by Sun because it consumes Solaris private interfaces). He should ask PADL for some fix. Not sure why Solaris 8 is OK for him. Your longer term solution - I think there are plans to move all naming requests to be process only by name service cache daemon, so in default mode applications will not be linked against some additional libraries than libc probably. Best regards, Milan _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
