Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2891933005:
Plumb sandbox rules through the helper executable. (Closed)
DescriptionPlumb sandbox rules through the helper executable.
Add code to the helper executable to send it the sandbox rules. The
helper executable will apply the sandbox rules to its process and
re-execute itself in the sandbox.
NOPRESUBMIT=true
BUG=689306
CQ-DEPEND=2907663002
Review-Url: https://codereview.chromium.org/2891933005
Cr-Commit-Position: refs/heads/master@{#475664}
Committed: https://chromium.googlesource.com/chromium/src/+/c95caf021bebd3bc58dafc206ff9f43678dc8d73
Patch Set 1 #Patch Set 2 : Add unit test for the new API #Patch Set 3 : Switch to new and delete #
Total comments: 17
Patch Set 4 : Address review feedback #
Total comments: 13
Patch Set 5 : Cleanup next round of feedback #
Total comments: 12
Patch Set 6 : Fix the last nits #Patch Set 7 : Rebase patch #
Messages
Total messages: 62 (45 generated)
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Description was changed from ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. BUG=689306 ========== to ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. BUG=689306 ==========
kerrnel@chromium.org changed reviewers: + mark@chromium.org
On 2017/05/22 18:01:51, Greg K wrote: > mailto:kerrnel@chromium.org changed reviewers: > + mailto:mark@chromium.org PTAL. Thanks, Greg
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:115: if (!exec_path) { I know Chrome doesn't use exceptions, but the underlying C++ new[] here and elsewhere in this file will throw an exception, which will be unhandled and terminate execution, rendering this check not needed, right? https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:144: snprintf(framework_path, framework_path_size, "%s/%s", parent_dir, rel_path); Unless there's a good reason to prefer C style format strings, should I replace this with std::string concatenation?
https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:33: constexpr char exec_param[] = "EXECUTABLE_PATH"; WHY ARE WE YELLING? https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:50: !server.SetParameter(pid_param, std::to_string(getpid()))) { #include <string> https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:51: fprintf(stderr, "Failed to setup parameters for sandbox.\n"); “set up” https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:61: strncmp(argv[i], fd_mapping_arg, strlen(fd_mapping_arg)) != 0) { Shouldn’t you be looking for “--fd_mapping=”? https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:68: execve(argv[0], new_argv.data(), nullptr); Why is envp nullptr? https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:87: fd_mapping = std::stoi(fd_str); This piece of junk will return 0 if fd_str isn’t really a number, which you’ll happily treat as a real file descriptor. (And it is a real file descriptor.) https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:115: if (!exec_path) { On 2017/05/22 18:34:03, Greg K wrote: > I know Chrome doesn't use exceptions, but the underlying C++ new[] here and > elsewhere in this file will throw an exception, which will be unhandled and > terminate execution, rendering this check not needed, right? Right. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:144: snprintf(framework_path, framework_path_size, "%s/%s", parent_dir, rel_path); Greg K wrote: > Unless there's a good reason to prefer C style format strings, should I replace > this with std::string concatenation? Whatever you prefer.
https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:33: constexpr char exec_param[] = "EXECUTABLE_PATH"; On 2017/05/22 18:53:18, Mark Mentovai wrote: > WHY ARE WE YELLING? All sandbox parameters are written in uppercase, so this continues that convention. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:50: !server.SetParameter(pid_param, std::to_string(getpid()))) { On 2017/05/22 18:53:17, Mark Mentovai wrote: > #include <string> Done. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:51: fprintf(stderr, "Failed to setup parameters for sandbox.\n"); On 2017/05/22 18:53:18, Mark Mentovai wrote: > “set up” Done. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:61: strncmp(argv[i], fd_mapping_arg, strlen(fd_mapping_arg)) != 0) { On 2017/05/22 18:53:18, Mark Mentovai wrote: > Shouldn’t you be looking for “--fd_mapping=”? Done. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:68: execve(argv[0], new_argv.data(), nullptr); On 2017/05/22 18:53:18, Mark Mentovai wrote: > Why is envp nullptr? Good catch, it needs to pass the current environment through. https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:87: fd_mapping = std::stoi(fd_str); On 2017/05/22 18:53:18, Mark Mentovai wrote: > This piece of junk will return 0 if fd_str isn’t really a number, which you’ll > happily treat as a real file descriptor. (And it is a real file descriptor.) libc++abi.dylib: terminating with uncaught exception of type std::invalid_argument: stoi: no conversion The behavior I read and saw is that it throws an exception. Is that not always true? https://codereview.chromium.org/2891933005/diff/40001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:144: snprintf(framework_path, framework_path_size, "%s/%s", parent_dir, rel_path); On 2017/05/22 18:53:18, Mark Mentovai wrote: > Greg K wrote: > > Unless there's a good reason to prefer C style format strings, should I > replace > > this with std::string concatenation? > > Whatever you prefer. Acknowledged.
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:55: return -1; This isn’t right for something that’s going to be used as main()’s exit code. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:55: return -1; I also don’t see any rhyme or reason to when you decided to return (and thus exit) and when you decided to abort(). Maybe there’s a distinction between the two that I don’t see. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:71: execve(argv[0], new_argv.data(), environ); NSGetExecutablePath() would be better than argv[0], since argv[0] can really be anything, including something that would make sense only given a $PATH search (execvp()), but also including something entirely unrelated to the executable. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:71: execve(argv[0], new_argv.data(), environ); Instead of declaring environ and calling execve(), you can just call execv() and let it deal with that for you. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:89: std::string fd_str = arg.substr(arg.find("=") + 1, arg.length()); You don’t need to find the = now. You know where it is based on the length of fd_mapping_arg. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:95: return -1; -1’s not right here either. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:155: // exit, don't return from main, to avoid the apparent removal of main from Shouldn’t this apply to the other early returns in this function?
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:55: return -1; On 2017/05/23 20:41:29, Mark Mentovai wrote: > I also don’t see any rhyme or reason to when you decided to return (and thus > exit) and when you decided to abort(). Maybe there’s a distinction between the > two that I don’t see. Yeah that was an oversight. Everything should just abort() if an unexpected condition happens. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:71: execve(argv[0], new_argv.data(), environ); On 2017/05/23 20:41:29, Mark Mentovai wrote: > Instead of declaring environ and calling execve(), you can just call execv() and > let it deal with that for you. Done. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:71: execve(argv[0], new_argv.data(), environ); On 2017/05/23 20:41:29, Mark Mentovai wrote: > NSGetExecutablePath() would be better than argv[0], since argv[0] can really be > anything, including something that would make sense only given a $PATH search > (execvp()), but also including something entirely unrelated to the executable. Done. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:89: std::string fd_str = arg.substr(arg.find("=") + 1, arg.length()); On 2017/05/23 20:41:28, Mark Mentovai wrote: > You don’t need to find the = now. You know where it is based on the length of > fd_mapping_arg. Done. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:95: return -1; On 2017/05/23 20:41:29, Mark Mentovai wrote: > -1’s not right here either. Done. https://codereview.chromium.org/2891933005/diff/60001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:155: // exit, don't return from main, to avoid the apparent removal of main from On 2017/05/23 20:41:29, Mark Mentovai wrote: > Shouldn’t this apply to the other early returns in this function? Yes although all the early returns should actually just be aborts.
LG otherwise! https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:34: constexpr char exec_param[] = "EXECUTABLE_PATH"; Not really necessary for this to be out here, it can go closer to the point of use in the function below. Same with pid_param. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:43: void SandboxExec(const char* exec_path, Now you can make this __attribute__((noreturn)) which may result in slightly better generated code in the caller (main()). https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:48: if (realpath(argv[0], rp) == NULL) Should we be using argv[0] or exec_path? https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:49: abort(); Did you want to perror() before abort() for things that set errno (like you did on line 73 and elsewhere)? https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:60: abort(); And perhaps fprintf(stderr) something for things that don’t (like you did on line 55). https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:135: const size_t parent_path_len = strlen(parent_dir); parent_dir_len instead of parent_path_len to make what it’s tracking clearer.
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. BUG=689306 ========== to ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 ==========
https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... File chrome/app/chrome_exe_main_mac.cc (right): https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:34: constexpr char exec_param[] = "EXECUTABLE_PATH"; On 2017/05/24 20:42:42, Mark Mentovai wrote: > Not really necessary for this to be out here, it can go closer to the point of > use in the function below. Same with pid_param. Done. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:43: void SandboxExec(const char* exec_path, On 2017/05/24 20:42:41, Mark Mentovai wrote: > Now you can make this __attribute__((noreturn)) which may result in slightly > better generated code in the caller (main()). Done. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:48: if (realpath(argv[0], rp) == NULL) On 2017/05/24 20:42:41, Mark Mentovai wrote: > Should we be using argv[0] or exec_path? Done. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:49: abort(); On 2017/05/24 20:42:41, Mark Mentovai wrote: > Did you want to perror() before abort() for things that set errno (like you did > on line 73 and elsewhere)? Done. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:60: abort(); On 2017/05/24 20:42:41, Mark Mentovai wrote: > And perhaps fprintf(stderr) something for things that don’t (like you did on > line 55). Done. https://codereview.chromium.org/2891933005/diff/80001/chrome/app/chrome_exe_m... chrome/app/chrome_exe_main_mac.cc:135: const size_t parent_path_len = strlen(parent_dir); On 2017/05/24 20:42:41, Mark Mentovai wrote: > parent_dir_len instead of parent_path_len to make what it’s tracking clearer. Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
kerrnel@chromium.org changed reviewers: + thakis@chromium.org
thakis@chromium.org: Please review changes in chrome/ Thanks, Greg
lgtm nit: i would've done the c -> cc rename in a separate change, to make it easier to see what you're changing in the cc file
On 2017/05/25 19:13:24, Nico wrote: > lgtm > > nit: i would've done the c -> cc rename in a separate change, to make it easier > to see what you're changing in the cc file That's a fair point for the future, but for now are you OK with moving forward with the change as is?
Up to you; you're the one most likely to look at `git blame` for the cc file On Thu, May 25, 2017 at 3:14 PM, <kerrnel@chromium.org> wrote: > On 2017/05/25 19:13:24, Nico wrote: > > lgtm > > > > nit: i would've done the c -> cc rename in a separate change, to make it > easier > > to see what you're changing in the cc file > > That's a fair point for the future, but for now are you OK with moving > forward > with the change as is? > > https://codereview.chromium.org/2891933005/ > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 ========== to ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 CQDEPEND=2907663002 ==========
Description was changed from ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 CQDEPEND=2907663002 ========== to ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 CQ-DEPEND=2907663002 ==========
The CQ bit was checked by kerrnel@chromium.org to run a CQ dry run
On 2017/05/25 19:15:27, chromium-reviews wrote: > Up to you; you're the one most likely to look at `git blame` for the cc file > > On Thu, May 25, 2017 at 3:14 PM, <mailto:kerrnel@chromium.org> wrote: > > > On 2017/05/25 19:13:24, Nico wrote: > > > lgtm > > > > > > nit: i would've done the c -> cc rename in a separate change, to make it > > easier > > > to see what you're changing in the cc file > > > > That's a fair point for the future, but for now are you OK with moving > > forward > > with the change as is? > > > > https://codereview.chromium.org/2891933005/ > > > > -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an email > to mailto:chromium-reviews+unsubscribe@chromium.org. Ok I submitted the rename separately and rebased this. Mark, PTAL. - Greg
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
If the diff against the previously-uploaded patch set is clean (except for unrelated changes in the tree), then this still LGTM.
On 2017/05/25 22:29:46, Mark Mentovai wrote: > If the diff against the previously-uploaded patch set is clean (except for > unrelated changes in the tree), then this still LGTM. Yes, it's clean, especially for chrome_exe_main_mac.cc. Thanks.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by kerrnel@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org Link to the patchset: https://codereview.chromium.org/2891933005/#ps120001 (title: "Rebase patch")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 120001, "attempt_start_ts": 1496169340331290,
"parent_rev": "30ff36523161aea9df5d4e787aac0bb9d532a205", "commit_rev":
"c95caf021bebd3bc58dafc206ff9f43678dc8d73"}
Message was sent while issue was closed.
Description was changed from ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 CQ-DEPEND=2907663002 ========== to ========== Plumb sandbox rules through the helper executable. Add code to the helper executable to send it the sandbox rules. The helper executable will apply the sandbox rules to its process and re-execute itself in the sandbox. NOPRESUBMIT=true BUG=689306 CQ-DEPEND=2907663002 Review-Url: https://codereview.chromium.org/2891933005 Cr-Commit-Position: refs/heads/master@{#475664} Committed: https://chromium.googlesource.com/chromium/src/+/c95caf021bebd3bc58dafc206ff9... ==========
Message was sent while issue was closed.
Committed patchset #7 (id:120001) as https://chromium.googlesource.com/chromium/src/+/c95caf021bebd3bc58dafc206ff9... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
