It sounds like this is going to break all file:// URI accesses until we finish implementing e10s support for them:
https://bugzilla.mozilla.org/show_bug.cgi?id=922481 That may be more bustage on nightly than is acceptable? Jason On Fri, Oct 7, 2016 at 9:49 AM, Gian-Carlo Pascutto <g...@mozilla.com> wrote: > Hi all, > > the next Nightly build will have a significantly tightened Linux > sandbox. Writes are no longer allowed except to shared memory (for IPC), > and to the system TMPDIR (and we're eventually going to get rid of the > latter, perhaps with an intermediate step to a Firefox-content-specific > tmpdir). > > There might be some compatibility fallout from this. Extensions/add-ons > that try to write from the content process will no longer work, but the > impact there should be limited given that similar (and stricter) > restrictions have been tried out on macOS. (See bug 1187099 and bug > 1288874 for info/discussion). Because Firefox currently still loads a > number of external libraries into the content process (glib, gtk, > pulseaudio, etc) there is some risk of breakage there as well. You know > where to report (Component: Security - Process Sandboxing). > > This behavior can be controlled via a pref: > pref("security.sandbox.content.level", 2); > > Reverting this to 1 goes back to the previous behavior where the set of > allowable system calls is restricted, but no filtering happens on > filesytem IO. > > When Firefox is built with debugging enabled, it will log any policy > violations. Currently, a clean Nightly build will show some of those. > They are inconsequential, and we'll deal with them, eventually. (Patches > welcome though!) > > -- > GCP > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Jason _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
