Only enable the seccomp sandbox, if the machine actually has kernel support for

this feature, and if no other obstacle prevents us from enabling it.

Otherwise, we print a warning message and continue running without the sandbox.
This is not ideal, but given the non-trivial number of users who might not have
seccomp enabled by default, this seems the prudent approach.

BUG=26521
Review URL: http://codereview.chromium.org/341092

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30966 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 17 insertions, 0 deletions

diff --git a/chrome/browser/zygote_main_linux.cc b/chrome/browser/zygote_main_linux.cc
index b9839d3..2b9d5fb 100644
--- a/chrome/browser/zygote_main_linux.cc
+++ b/chrome/browser/zygote_main_linux.cc
@@ -40,6 +40,8 @@
 
 #include "skia/ext/SkFontHost_fontconfig_control.h"
 
+#include "sandbox/linux/seccomp/sandbox.h"
+
 #include "unicode/timezone.h"
 
 // http://code.google.com/p/chromium/wiki/LinuxZygote
@@ -581,6 +583,21 @@ bool ZygoteMain(const MainFunctionParams& params) {
   g_am_zygote_or_renderer = true;
 #endif
 
+  if (CommandLine::ForCurrentProcess()->HasSwitch(
+          switches::kEnableSeccompSandbox)) {
+    if (!SupportsSeccompSandbox()) {
+      // There are a good number of users who cannot use the seccomp sandbox
+      // (e.g. because their distribution does not enable seccomp mode by
+      // default). While we would prefer to deny execution in this case, it
+      // seems more realistic to continue in degraded mode.
+      LOG(ERROR) << "WARNING! This machine lacks support needed for the "
+                    "Seccomp sandbox. Running renderers with Seccomp "
+                    "sandboxing disabled.";
+    } else {
+      LOG(INFO) << "Enabling experimental Seccomp sandbox.";
+    }
+  }
+
   if (!EnterSandbox()) {
     LOG(FATAL) << "Failed to enter sandbox. Fail safe abort. (errno: "
                << errno << ")";