Nelson Bolyard wrote: > Milan Jurik wrote, On 2008-07-23 02:14: > >> 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). > > Above you wrote that "In Solaris, there are two known backends ... and > PADL/OpenLDAP backend.", then you wrote that "LDAP backend ... not > supported by Sun". I'm surprised that PADL would be "In Solaris", but > "not supported by Sun". Did you perhaps mean that the PADL backend is > available (from third parties) for Solaris, but is not officially a > part of Solaris, and hence is not supported? > > Is it possible that PADL now attempts to support/use either/both of > NSS and OpenSSL ? The strace output surely seems to suggest that.
That's not quite accurate. PADL's nss_ldap can be built against any LDAP library, including both Mozilla's and OpenLDAP's. (And I guess Solaris currently is bundled with their own build of the Mozilla LDAP library.) Of course it can only be built against one at a time. Sun's native nss_ldap is only built with their copy of MozLDAP, of course. What's likely (and indeed, happens quite often on Solaris) is that nss_ldap (Sun native or PADL, doesn't matter which) was invoked to perform some incidental lookup (uid to name, hostname to IP, etc.) which caused it to initialize the Solaris LDAP library. Part of that initialization procedure would include initializing MozNSS. Then if some 3rd party module was linked against OpenLDAP and also loaded in the process, it's possible that a call into the Solaris LDAP library would eventually reference a symbol that was resolved in the OpenLDAP library. At that point, if OpenLDAP's library init had not been called yet, it would be done implicitly, which could also cause it to initialize OpenSSL at that time. >> He should ask PADL for some fix. Not sure why Solaris 8 is OK for him. > > If he's using S10's native LDAP backend (which uses NSS) or some version of > PADL that uses NSS crypto on S10, but is running the native LDAP backend on > S8, then that explains it, I believe. > > In S8, the native ldap backend shared library had its own private copy of > NSS linked inside of it. It did not use NSS shared libraries. > Consequently, when it initialized NSS, it was not initializing the shared > library copy that was being used by FF/TB, and so there was no conflict > between the two NSSes. > > In S10, the native nss_ldap uses the NSS shared libraries, which FF/TB > also use, so whoever initializes NSS first, wins. From the first post, apparently the native nss wins. I've been reading the NSS code for the past few hours and it seems the only way to avoid this problem is to change the standard practice in coding apps that use NSS. Instead of calling NSS_Init, they should call NSS_NoDB_Init and then use explicitly opened DBs throughout. Ironically, we see comments like this: nss/lib/certdb/certdb.c:1382 /* * Allow use of default cert database, so that apps(such as mozilla) don't * have to pass the handle all over the place. */ static CERTCertDBHandle *default_cert_db_handle = 0; -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
