The firefox start script in MOZILLA_FIVE_HOME sets LD_LIBRARY_PATH to include
MOZILLA_FIVE_HOME and a number of subdirectories of MOZILLA_FIVE_HOME. The
current NSS provider does open libnss3.so in the path which is configured in nss.cfg, but the dlopen call doesn't the depending libraries of libnss3.so in the same directory.
The firefox start script in MOZILLA_FIVE_HOME sets LD_LIBRARY_PATH to include
MOZILLA_FIVE_HOME and a number of subdirectories of MOZILLA_FIVE_HOME. The
current NSS provider does open libnss3.so in the path which is configured in nss.cfg, but the dlopen call doesn't the depending libraries of libnss3.so in the same directory.
$ LD_LIBRARY_ PATH=/usr/ lib/firefox- 3.6.3 ldd /usr/lib/libnss3.so firefox- 3.6.3/libnssuti l3.so (0x006a8000) firefox- 3.6.3/libplc4. so (0x00f93000) firefox- 3.6.3/libplds4. so (0x003bb000) firefox- 3.6.3/libnspr4. so (0x00f40000) i686/cmov/ libpthread. so.0 (0x00252000) i686/cmov/ libdl.so. 2 (0x0062d000) i686/cmov/ libc.so. 6 (0x0090b000)
linux-gate.so.1 => (0x0068d000)
libnssutil3.so => /usr/lib/
libplc4.so => /usr/lib/
libplds4.so => /usr/lib/
libnspr4.so => /usr/lib/
libpthread.so.0 => /lib/tls/
libdl.so.2 => /lib/tls/
libc.so.6 => /lib/tls/
/lib/ld-linux.so.2 (0x002af000)
This happens as well with the firefox binaries which are downloadable from mozilla.org.
The security provider should prepend nssLibraryDirectory to the LD_LIBRARY_PATH before dlopening libnss3, and after that restore the path.
The workaround looks ok, just ignoring the libs provided by firefox, and using the libs detected at build time.