This way they'll continue to be at the beginning of the symbol search
path after mozsandbox returns to being a shared library instead of
statically linked into plugin-container.
--HG--
rename : security/sandbox/linux/SandboxHooks.cpp => security/sandbox/linux/interpose/SandboxHooks.cpp
Removes global write access from the content process (instead of
just blocking write access to $HOME) for level 1 and 2 Mac content
sandboxes. Allows writes to /private/var/folders/[0-9][0-9]/ in
DEBUG mode so that leaktest can continue to work.
MozReview-Commit-ID: 635o7Nj9oW1
--HG--
extra : rebase_source : 7e23612f56a31de83307057c1e6d0eaadb937614
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 8cb5ea82004ad631fe688bafffa9dc9979568679
This also reverts the Bug 1287426 Part 8 patch that turned the USER_NON_ADMIN loken into a restricted token.
MozReview-Commit-ID: 9fNeyhAHw55
--HG--
extra : rebase_source : adbe59260d512b5d17b6e3ea6c1fe484c06eb555
Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
This is to work around an issue where the call to CoInitializeSecurity in MainThreadRuntime::InitializeSecurity causes the impersonation token, used to give the pre-lockdown permissions, to be replaced with one with no rights.
This only seems to happen when the lockdown token is USER_NON_ADMIN, which is not a restricted token.
MozReview-Commit-ID: 6HFuDFmWLTf
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : d91d8939cabb0eed36b640766756548a790a301c
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
--HG--
extra : rebase_source : 7bf426f14f31b35c8b541e6d21183226db9836c7
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Allow /System/Library/PrivateFrameworks/ to be read from the from the plugin sandbox.
--HG--
extra : rebase_source : 8b71b7daed4792d8ce67131819c90acb2f5891ea
Making readlink() always fail with EINVAL (the result of applying it
to a non-symlink) worked on B2G, but this is not the case on desktop.
(Note: originally the idea for the B2G file broker was that it would
ignore symlinks and map lstat to stat, so that behavior for readlink
would have been consistent, but as eventually implemented it does do
lstat as actual lstat.)
In particular, this seems to be causing something in the graphics
library stack to change what GL renderer it uses (?), and on some
systems the presence of the readlink->EINVAL rule causes it to load a
version of the llvmpipe software renderer with a crash bug, instead of
(we assume) some other driver that works.
