Comment 18 for bug 561124

Revision history for this message
In , Matthias Klose (doko) wrote :

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
 linux-gate.so.1 => (0x0068d000)
 libnssutil3.so => /usr/lib/firefox-3.6.3/libnssutil3.so (0x006a8000)
 libplc4.so => /usr/lib/firefox-3.6.3/libplc4.so (0x00f93000)
 libplds4.so => /usr/lib/firefox-3.6.3/libplds4.so (0x003bb000)
 libnspr4.so => /usr/lib/firefox-3.6.3/libnspr4.so (0x00f40000)
 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00252000)
 libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x0062d000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x0090b000)
 /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.