For Mac and Linux, on developer non-packaged builds, our content sandbox rules need to whitelist the repo directory and the object directory because. This is because (using Mac as an example) the Nightly.app/ bundle includes symlinks to resource files from the repo and object directories. The .app bundle is already whitelisted, but in order to read a file outside of that directory, we must know the paths in order to whitelist them. (Our Linux implementation might end up not needing this whitelisting. TBD.) The use of whitelisting is determined at runtime using IsDevelopmentBuild() which returns true if the omnijar is unpacked. It was requested in bug 1380690 that we make this whitelisting only be applied to non-release builds using a compile-time flag rather than a runtime decision. Per <https://bugzilla.mozilla.org/show_bug.cgi?id=1380690#c38>, this requires some moz.build changes. If we have a compile-time flag that allows us to identify when we are running on an unpackaged dev build, we can change IsDevelopmentBuild() to use this flag and more accurately name the function IsUnpackedDevelopmentBuild().  http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/security/sandbox/common/SandboxSettings.cpp#15
This requires at least bug 1382697 to make the file installation mode configurable. Once that is in place, there's still some plumbing to change the installation mode for builds in CI. But that could be done in this bug. Work that is unblocked is modifying the code added in https://hg.mozilla.org/mozilla-central/rev/db6d70745294 and https://hg.mozilla.org/mozilla-central/rev/225827d9f375 to be conditional on a TBD build configuration (we can use #ifdef TRUE as a stop-gap or something). IMO we shouldn't even compile that backdoor code in a distributed Firefox build. But inaccessible code is essentially the same. So I'll defer to the sandbox team for C++ decisions: they own the code.
Depends on: 1382697
You need to log in before you can comment on or make changes to this bug.