When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
All prefs that need to be sent to a new content process are now put into the
shared memory segment, and they are identified by the pref name instead of an
index into a list. The old IPC used at process startup (in XPCOMInitData) is
removed.
Benefits:
- It removes the need for the early prefs list
(dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly
and often trips people up (e.g. bug 1432979, bug 1439406).
- Using prefnames instead of indices fixes some fragility (fixing bug 1419432).
- It fixes the problem of early prefs being installed as unlocked default
values even if they are locked and/or have user values.
MozReview-Commit-ID: FRIzHF8Tjd
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
This code is used to detect too-early accesses of prefs in content processes.
The patch makes the following changes.
- New terminology: "early" prefs are those sent via the command line; "late"
prefs are those sent via IPC. Previously the former were "init" prefs and the
latter didn't have a clear name.
- The phase tracking and checking is now almost completely encapsulated within
Preferences.cpp. The only exposure to outside code is via the
AreAllPrefsSetInContentProcess() method, which has a single use.
- The number of states tracked drops from 5 to 3. There's no need to track the
beginning of the pref-setting operations, because we only need to know if
they've finished. (This also avoids the weirdness where we could transition
from END_INIT_PREFS back to BEGIN_INIT_PREFS because of the way -intPrefs,
-boolPrefs and -stringPrefs were parsed separately.)
MozReview-Commit-ID: IVJWiDxdsDV
--HG--
extra : rebase_source : 8cee1dcbd40847bf052ca9e2b759dd550350e5a1
This makes the IPC messages a little bigger, but that's unavoidable.
MozReview-Commit-ID: 1oPz2Yjjd9y
--HG--
extra : rebase_source : 0cff8cf5b25f66b73f6864ce50c1e5f575026ec3
It represents a pref, so `Pref` is a better name. Within Preferences.cpp the
patch uses domPref/aDomPref to distinguish it from PrefHashEntry values.
MozReview-Commit-ID: HXTl0GX4BtO
--HG--
extra : rebase_source : c1e0726c55e7577720f669f0ed2dbc38627d853e
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : b9130f522e860e6a582933799a9bac07b771139b
This patch moves handling of the "MOZ_DISABLE_CONTENT_SANDBOX" environment
variable into GetEffectiveContentSandboxLevel. It also introduces
IsContentSandboxEnabled and ports many users of GetEffectiveContentSandboxLevel
to use it.
MozReview-Commit-ID: 4CsOf89vlRB
--HG--
extra : rebase_source : 10234bd7d837eae8dc915e4a0c0a37040fd0a280
In some unknown circumstance, possibly if the parent process has a
different version than the child process, the child does not receive
scheduler prefs, which makes it read out of an uninitialized local
variable. This can probably happen because the scheduler prefs are
checked before we do the ContentChild::Init version check. Bill also
suggested that the pref env var might be getting truncated.
This patch improves on the situation by using null for the prefs array
if none was sent, and falling back on the default values, which leave
the scheduler disabled.
This also checks that the pref string is at least long enough to avoid
a buffer overflow. Note that if the end of the string isn't an integer
we'll end up with an sPrefThreadCount of zero, which can't be good.
MozReview-Commit-ID: ByHLFMEpgyZ
--HG--
extra : rebase_source : 8f6368b88ec3746f4d1c7716a962bb2ac3c2f3b5
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
When a subprocess is launched, gfxVars updates (for non-default values) are
serialized and passed on the command line, up to a limit of 1023 characters,
and ensuring it should not overflow the command line size.
When the child starts, the command line parameter is given to gfxVars, so the
updates can be used during gfxVars::Initialize(), instead of doing a sync
request to the parent.
In case the updates are not sent, or in the unlikely case the child cannot
parse them, we fallback to the sync request -- The former case should be rare
enough that a slow sync request is acceptable: It should only happen if D3D
block-list is *modified* (most people would either use the default, or just
overwrite these prefs with short strings.)
MozReview-Commit-ID: 6MoJC0fe59Q
--HG--
extra : rebase_source : cdc2e451783160c579b8fc84050e8457c600523e
the << operator of std:stringstream is occationally hanging on Windows 7 PGO builds, this uses nsPrintfCString to do formatting rather than stringstreams and replaces the std::string with nsFixedCSting for string building
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 change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
The previous patch in this series creates a new directory service entry
specifically for obtaining the content process temp directory.
This patch converts everything else to reference that entry. It also sets
appropriate environment variables in the content processes so that system
APIs automatically pick up the directory. This is necessary for the crash
reporter to be able to call those APIs in exception handling contexts.
MozReview-Commit-ID: DF6aNKrWnWp
--HG--
extra : rebase_source : 3cc914f5d369dbc70f03fa4cb68a7eab0cc1be59
Modify the Mac sandbox to allow temporary files to be created in a
parent-specified subdirectory of NS_OS_TEMP_DIR. This is similar to the
Windows approach. The parent provides a UUID in a preference which is
used by the content process to form the subdirectory name.
MozReview-Commit-ID: 6BONpfZz8ZI
--HG--
extra : rebase_source : ad18e091918356a1a40c13f1453972b4512ad476
Tiberius Oros
Haik Aftandilian
Brian Hackett
Kris Maglione
Brindusan Cristian
Margareta Eliza Balazs
Stephen A Pohl
Nicholas Nethercote
Alex Gaynor
shindli
Andrew McCreight
Bill McCloskey
Sebastian Hengst
Phil Ringnalda
Gerald Squelart
Brad Lassey
Dave Townsend
Masatoshi Kimura
Aaron Klotz
Birunthan Mohanathas
Bob Owen
David Anderson