2015-05-03 22:32:37 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
2012-05-21 15:12:37 +04:00
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2010-05-14 03:44:53 +04:00
|
|
|
#include "mozilla/ipc/IOThreadChild.h"
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2010-07-19 22:33:33 +04:00
|
|
|
#include "ContentProcess.h"
|
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium.
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
2018-02-16 09:54:16 +03:00
|
|
|
#include "base/shared_memory.h"
|
|
|
|
#include "mozilla/Preferences.h"
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_MACOSX) && defined(MOZ_SANDBOX)
|
2016-03-08 22:02:27 +03:00
|
|
|
# include <stdlib.h>
|
2018-10-18 23:47:43 +03:00
|
|
|
# include "mozilla/Sandbox.h"
|
2016-03-08 22:02:27 +03:00
|
|
|
#endif
|
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if (defined(XP_WIN) || defined(XP_MACOSX)) && defined(MOZ_SANDBOX)
|
2017-05-13 00:04:42 +03:00
|
|
|
# include "mozilla/SandboxSettings.h"
|
2016-03-08 22:02:27 +03:00
|
|
|
# include "nsAppDirectoryServiceDefs.h"
|
2015-04-05 16:01:38 +03:00
|
|
|
# include "nsDirectoryService.h"
|
|
|
|
# include "nsDirectoryServiceDefs.h"
|
|
|
|
#endif
|
|
|
|
|
2020-10-28 15:31:35 +03:00
|
|
|
#include "nsAppRunner.h"
|
|
|
|
#include "ProcessUtils.h"
|
|
|
|
|
2010-05-14 03:44:53 +04:00
|
|
|
using mozilla::ipc::IOThreadChild;
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2020-11-04 20:04:01 +03:00
|
|
|
namespace mozilla::dom {
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_WIN) && defined(MOZ_SANDBOX)
|
2016-03-08 22:02:27 +03:00
|
|
|
static void SetTmpEnvironmentVariable(nsIFile* aValue) {
|
|
|
|
// Save the TMP environment variable so that is is picked up by GetTempPath().
|
|
|
|
// Note that we specifically write to the TMP variable, as that is the first
|
|
|
|
// variable that is checked by GetTempPath() to determine its output.
|
|
|
|
nsAutoString fullTmpPath;
|
|
|
|
nsresult rv = aValue->GetPath(fullTmpPath);
|
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
return;
|
|
|
|
}
|
2016-09-02 10:12:24 +03:00
|
|
|
Unused << NS_WARN_IF(!SetEnvironmentVariableW(L"TMP", fullTmpPath.get()));
|
2016-03-08 22:02:27 +03:00
|
|
|
// We also set TEMP in case there is naughty third-party code that is
|
|
|
|
// referencing the environment variable directly.
|
2016-09-02 10:12:24 +03:00
|
|
|
Unused << NS_WARN_IF(!SetEnvironmentVariableW(L"TEMP", fullTmpPath.get()));
|
2016-02-26 02:26:13 +03:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_WIN) && defined(MOZ_SANDBOX)
|
2015-04-05 16:01:38 +03:00
|
|
|
static void SetUpSandboxEnvironment() {
|
|
|
|
MOZ_ASSERT(
|
|
|
|
nsDirectoryService::gService,
|
|
|
|
"SetUpSandboxEnvironment relies on nsDirectoryService being initialized");
|
|
|
|
|
2018-02-13 18:11:26 +03:00
|
|
|
// On Windows, a sandbox-writable temp directory is used whenever the sandbox
|
|
|
|
// is enabled.
|
2017-06-01 17:38:22 +03:00
|
|
|
if (!IsContentSandboxEnabled()) {
|
2015-04-05 16:01:38 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-03-08 22:02:27 +03:00
|
|
|
nsCOMPtr<nsIFile> sandboxedContentTemp;
|
|
|
|
nsresult rv = nsDirectoryService::gService->Get(
|
|
|
|
NS_APP_CONTENT_PROCESS_TEMP_DIR, NS_GET_IID(nsIFile),
|
|
|
|
getter_AddRefs(sandboxedContentTemp));
|
2015-05-18 13:51:07 +03:00
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
2015-04-05 16:01:38 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-02-26 02:26:13 +03:00
|
|
|
// Change the gecko defined temp directory to our sandbox-writable one.
|
2015-05-18 13:51:07 +03:00
|
|
|
// Undefine returns a failure if the property is not already set.
|
2015-11-02 08:53:26 +03:00
|
|
|
Unused << nsDirectoryService::gService->Undefine(NS_OS_TEMP_DIR);
|
2016-03-08 22:02:27 +03:00
|
|
|
rv = nsDirectoryService::gService->Set(NS_OS_TEMP_DIR, sandboxedContentTemp);
|
2015-05-18 13:51:07 +03:00
|
|
|
if (NS_WARN_IF(NS_FAILED(rv))) {
|
|
|
|
return;
|
|
|
|
}
|
2016-03-08 22:02:27 +03:00
|
|
|
|
|
|
|
SetTmpEnvironmentVariable(sandboxedContentTemp);
|
2015-04-05 16:01:38 +03:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-02-05 08:52:38 +03:00
|
|
|
bool ContentProcess::Init(int aArgc, char* aArgv[]) {
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
Maybe<uint64_t> childID;
|
|
|
|
Maybe<bool> isForBrowser;
|
2018-05-08 17:31:44 +03:00
|
|
|
Maybe<const char*> parentBuildID;
|
2019-01-11 21:39:22 +03:00
|
|
|
char* prefsHandle = nullptr;
|
|
|
|
char* prefMapHandle = nullptr;
|
|
|
|
char* prefsLen = nullptr;
|
|
|
|
char* prefMapSize = nullptr;
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_MACOSX) && defined(MOZ_SANDBOX)
|
2017-02-05 08:52:38 +03:00
|
|
|
nsCOMPtr<nsIFile> profileDir;
|
2016-08-30 23:32:21 +03:00
|
|
|
#endif
|
|
|
|
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
for (int i = 1; i < aArgc; i++) {
|
|
|
|
if (!aArgv[i]) {
|
2017-02-05 08:52:38 +03:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
if (strcmp(aArgv[i], "-appdir") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
2017-02-05 08:52:38 +03:00
|
|
|
}
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
nsDependentCString appDir(aArgv[i]);
|
2017-02-05 08:52:38 +03:00
|
|
|
mXREEmbed.SetAppDir(appDir);
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
|
|
|
|
} else if (strcmp(aArgv[i], "-childID") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
2017-02-05 08:52:38 +03:00
|
|
|
}
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
char* str = aArgv[i];
|
|
|
|
childID = Some(strtoull(str, &str, 10));
|
|
|
|
if (str[0] != '\0') {
|
|
|
|
return false;
|
2017-02-05 08:52:38 +03:00
|
|
|
}
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
|
|
|
|
} else if (strcmp(aArgv[i], "-isForBrowser") == 0) {
|
|
|
|
isForBrowser = Some(true);
|
|
|
|
|
|
|
|
} else if (strcmp(aArgv[i], "-notForBrowser") == 0) {
|
|
|
|
isForBrowser = Some(false);
|
|
|
|
|
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium.
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
2018-02-16 09:54:16 +03:00
|
|
|
#ifdef XP_WIN
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-prefsHandle") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-01-11 21:39:22 +03:00
|
|
|
prefsHandle = aArgv[i];
|
2018-07-03 01:40:38 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-prefMapHandle") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-01-11 21:39:22 +03:00
|
|
|
prefMapHandle = aArgv[i];
|
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium.
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
2018-02-16 09:54:16 +03:00
|
|
|
#endif
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
|
|
|
|
} else if (strcmp(aArgv[i], "-prefsLen") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-01-11 21:39:22 +03:00
|
|
|
prefsLen = aArgv[i];
|
2018-07-03 01:40:38 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-prefMapSize") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-01-11 21:39:22 +03:00
|
|
|
prefMapSize = aArgv[i];
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-safeMode") == 0) {
|
2017-02-09 02:45:01 +03:00
|
|
|
gSafeMode = true;
|
2017-02-05 08:52:38 +03:00
|
|
|
|
2018-05-08 17:31:44 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-parentBuildID") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
parentBuildID = Some(aArgv[i]);
|
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_MACOSX) && defined(MOZ_SANDBOX)
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
} else if (strcmp(aArgv[i], "-profile") == 0) {
|
|
|
|
if (++i == aArgc) {
|
|
|
|
return false;
|
2017-02-05 08:52:38 +03:00
|
|
|
}
|
|
|
|
bool flag;
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
nsresult rv = XRE_GetFileFromPath(aArgv[i], getter_AddRefs(profileDir));
|
|
|
|
if (NS_FAILED(rv) || NS_FAILED(profileDir->Exists(&flag)) || !flag) {
|
2017-02-05 08:52:38 +03:00
|
|
|
NS_WARNING("Invalid profile directory passed to content process.");
|
|
|
|
profileDir = nullptr;
|
|
|
|
}
|
2019-03-19 01:31:59 +03:00
|
|
|
#endif /* XP_MACOSX && MOZ_SANDBOX */
|
2017-02-05 08:52:38 +03:00
|
|
|
}
|
|
|
|
}
|
2017-11-30 01:14:32 +03:00
|
|
|
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
// Did we find all the mandatory flags?
|
|
|
|
if (childID.isNothing() || isForBrowser.isNothing() ||
|
2019-01-23 04:16:56 +03:00
|
|
|
parentBuildID.isNothing()) {
|
Bug 1447246 - Refactor ContentProcess::Init(). r=jimm
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
2018-03-16 04:23:10 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-10-28 15:31:35 +03:00
|
|
|
::mozilla::ipc::SharedPreferenceDeserializer deserializer;
|
2019-01-11 21:39:22 +03:00
|
|
|
if (!deserializer.DeserializeFromSharedMemory(prefsHandle, prefMapHandle,
|
|
|
|
prefsLen, prefMapSize)) {
|
2018-07-24 18:46:38 +03:00
|
|
|
return false;
|
Bug 1438678 - Pass early prefs via shared memory instead of the command line. r=bobowen,jld,glandium.
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
2018-02-16 09:54:16 +03:00
|
|
|
}
|
|
|
|
|
2017-02-05 08:52:38 +03:00
|
|
|
mContent.Init(IOThreadChild::message_loop(), ParentPid(), *parentBuildID,
|
2020-02-07 01:41:56 +03:00
|
|
|
IOThreadChild::TakeChannel(), *childID, *isForBrowser);
|
2018-07-22 14:50:28 +03:00
|
|
|
|
2017-02-05 08:52:38 +03:00
|
|
|
mXREEmbed.Start();
|
2019-03-19 01:31:59 +03:00
|
|
|
#if (defined(XP_MACOSX)) && defined(MOZ_SANDBOX)
|
2017-02-05 08:52:38 +03:00
|
|
|
mContent.SetProfileDir(profileDir);
|
2018-10-18 23:47:43 +03:00
|
|
|
# if defined(DEBUG)
|
2020-03-17 21:29:03 +03:00
|
|
|
if (IsContentSandboxEnabled()) {
|
2018-10-18 23:47:43 +03:00
|
|
|
AssertMacSandboxEnabled();
|
|
|
|
}
|
|
|
|
# endif /* DEBUG */
|
2019-03-19 01:31:59 +03:00
|
|
|
#endif /* XP_MACOSX && MOZ_SANDBOX */
|
2016-08-30 23:32:21 +03:00
|
|
|
|
2019-03-19 01:31:59 +03:00
|
|
|
#if defined(XP_WIN) && defined(MOZ_SANDBOX)
|
2017-02-05 08:52:38 +03:00
|
|
|
SetUpSandboxEnvironment();
|
2015-04-05 16:01:38 +03:00
|
|
|
#endif
|
2016-02-26 02:26:13 +03:00
|
|
|
|
2017-02-05 08:52:38 +03:00
|
|
|
return true;
|
2009-07-01 00:39:22 +04:00
|
|
|
}
|
|
|
|
|
2015-05-20 11:58:32 +03:00
|
|
|
// Note: CleanUp() never gets called in non-debug builds because we exit early
|
|
|
|
// in ContentChild::ActorDestroy().
|
2010-07-19 22:33:33 +04:00
|
|
|
void ContentProcess::CleanUp() { mXREEmbed.Stop(); }
|
2009-07-01 00:39:22 +04:00
|
|
|
|
2020-11-04 20:04:01 +03:00
|
|
|
} // namespace mozilla::dom
|