1143733 - Firefox should not load libraries from outside app bundle, that conflict with those included in app bundle

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P3)

Description

[ruby]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

1. Create any dummy library
2. Place it into `/usr/local/lib` under the name `libnss3.dylib`
3. Launch Firefox



Actual results:

Fake `libnss3.dylib` is also present in list of Firefox's loaded modules


Expected results:

Firefox already has `libnss3.dylib` in it's app bundle directory, so it
1) should not look for alternatives when there is prioritized built-in
2) load multiple instances of library with same name, but different path

Comment 1

[Mike Hommey [:glandium]]

Can you attach the output of the following commands:
- otool -l /path/to/Firefox.app/Contents/MacOS/firefox
- DYLD_PRINT_LIBRARIES=1 /path/to/Firefox.app/Contents/MacOS/firefox

Comment 2

[ruby]

Attachment: `otool -l` for release Firefox

Comment 3

[ruby]

Attachment: `otool -l` for nightly Firefox

Comment 4

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for release Firefox without Homebrew conflict

Comment 5

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for release Firefox with Homebrew conflict

Comment 6

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for nightly Firefox without Homebrew conflict

Comment 7

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for nightly Firefox with Homebrew conflict

Comment 8

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for nightly Firefox+e10s without Homebrew conflict

Comment 9

[ruby]

Attachment: DYLD_PRINT_LIBRARIES=1 for nightly Firefox+e10s with Homebrew conflict

Comment 10

[ruby]

Unfortunately I found no way to enable verbose logging for release Firefox, so I'm including dyld log for Nighly for reference. I've replaced long paths with shell-like variables to reduce noise and ease reading, all expansions are included for reference.

Comment 11

[Mike Hommey [:glandium]]

The most relevant parts of those logs:
[0.034] dyld: loaded: ${RELEASE_APP_BUNDLE}/Contents/MacOS/libnss3.dylib
[0.724] dyld: loaded: ${RELEASE_APP_BUNDLE}/Contents/MacOS/libnssckbi.dylib
[1.577] dyld: loaded: ${HOMEBREW_PREFIX}/lib/libnss3.dylib

nssckbi is (maybe*) dlopening libnss3. It should be given the already loaded one, but for some reason, it's getting the one from homebrew...

* considering the time delay between the loading of nssckbi and homebrew's libnss3, it's not entirely clear that it's the case, but it's likely.

Comment 12

[Edouard Oger [:eoger]]

I was not able to reproduce the bug anymore, checking with both DYLD_PRINT_LIBRARIES=1 and lsof.
Do we have any reason to think we may have fixed the bug somehow?