Add flags for v2 sandbox to Chrome and Helper executable.

chrome/app/chrome_exe_main_mac.cc

Index: chrome/app/chrome_exe_main_mac.cc
diff --git a/chrome/app/chrome_exe_main_mac.cc b/chrome/app/chrome_exe_main_mac.cc
index f446f445864a359ec57e120b5163082fd180c878..c420b3d49a3cf9276215948218a4e0ea8611becd 100644
--- a/chrome/app/chrome_exe_main_mac.cc
+++ b/chrome/app/chrome_exe_main_mac.cc
@@ -32,6 +32,11 @@ typedef int (*ChromeMainPtr)(int, char**);
 #if defined(HELPER_EXECUTABLE)
 // The command line parameter to engage the v2 sandbox.
 constexpr char v2_sandbox_arg[] = "--v2-sandbox";
+// The command line paramter indicating that the v2 sandbox is enabled. This
+// must be different than the "v2-sandbox" flag to avoid endless re-executing.
+// The flag tells the sandbox initialization code inside Chrome that the sandbox
+// should already be enabled.
+char v2_sandbox_enabled_arg[] = "--v2-sandbox-enabled";

[Robert Sesek, 2017/06/01 22:07:49]

constexpr?

[Robert Sesek, 2017/06/01 22:07:49]

Since "enabled" is so overloaded for features, I think maybe
"--v2-sandbox-did-exec" or something more explicit?

Also, I wonder if it'd be better to negate this? I.e., the browser launches with
--v2-sandbox-exec and then the flag is removed from the argv before execv. Not
sure it makes a difference, other than all running child processes then won't
have the --v2-sandbox-exec flag in the args.

[Greg K, 2017/06/01 22:10:40]

The reason I make it a positive for now is because we're transitioning one
process type at a time, so this means all processes will have some
--not-v2-sandbox flag. I think we should use a positive flag and then flip that
around once the migration is complete?

[Robert Sesek, 2017/06/01 22:12:28]

That's true, unless you propagated the --v2-sandbox flag rather than dropping it
in the new process. It's fine to keep it positive until the transition is
complete. Maybe leave a TODO for this?

[Greg K, 2017/06/01 22:13:22]

Yes. I don't want to re-add the new flag because it gets confusing as it can
cause an endless re-exec cycle, unless it's add just before entering ChromeMain.
I'll add a TODO, thanks.

[Greg K, 2017/06/01 22:23:56]

I don't actually know a better way to do this. The execv() API takes a "char*
const" of all things, not even a const char*, so if this is constexpr, the only
way to pass it along is to throw away the const qualifier. 

Do you know a better way?

[Greg K, 2017/06/01 22:26:11]

For what it's worth, these are document as constants but kept non-const in
declaration to avoid breaking old code. I am fine using a const_cast<> in this
case: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

 // The command line parameter for the file descriptor used to receive the
 // sandbox policy.
 constexpr char fd_mapping_arg[] = "--fd_mapping=";
@@ -71,6 +76,8 @@ __attribute__((noreturn)) void SandboxExec(const char* exec_path,
       new_argv.push_back(argv[i]);
     }
   }
+  // Tell Chrome that the sandbox should already be enabled.
+  new_argv.push_back(v2_sandbox_enabled_arg);
   new_argv.push_back(nullptr);
 
   // The helper executable re-executes itself under the sandbox.