Unify the sandboxed vs. unsandboxed code paths more, for two reasons:

content/browser/zygote_main_linux.cc

Index: content/browser/zygote_main_linux.cc
===================================================================
--- content/browser/zygote_main_linux.cc	(revision 132258)
+++ content/browser/zygote_main_linux.cc	(working copy)
@@ -854,6 +854,10 @@
 
 #if !defined(CHROMIUM_SELINUX)
 static bool EnterSandbox() {
+  PreSandboxInit();
+  SkiaFontConfigSetImplementation(
+      new FontConfigIPC(kMagicSandboxIPCDescriptor));
+

[Jorge Lucangeli Obes, 2012/04/16 19:59:28]

So this will do the pre-sandbox init even if the SUID sandbox is not enabled,
because we also need the pre-init for the new seccomp sandbox right?

Does SkiaFontConfigSetImplementation(new
FontConfigIPC(kMagicSandboxIPCDescriptor)) work when the SUID sandbox is not
enabled? Given that most tests in the trybots run without the SUID sandbox, the
green try run suggests it does, but no harm in testing explicitly.

   // The SUID sandbox sets this environment variable to a file descriptor
   // over which we can signal that we have completed our startup and can be
   // chrooted.
@@ -870,8 +874,6 @@
       return false;
     const int fd = fd_long;
 
-    PreSandboxInit();
-
     static const char kMsgChrootMe = 'C';
     static const char kMsgChrootSuccessful = 'O';
 
@@ -894,9 +896,6 @@
       return false;
     }
 
-    SkiaFontConfigSetImplementation(
-        new FontConfigIPC(kMagicSandboxIPCDescriptor));
-
 #if !defined(OS_OPENBSD)
     // Previously, we required that the binary be non-readable. This causes the
     // kernel to mark the process as non-dumpable at startup. The thinking was
@@ -924,14 +923,6 @@
       }
     }
 #endif
-#if defined(SECCOMP_SANDBOX)
-  } else if (SeccompSandboxEnabled()) {
-    PreSandboxInit();
-    SkiaFontConfigSetImplementation(
-        new FontConfigIPC(kMagicSandboxIPCDescriptor));
-#endif
-  } else {
-    SkiaFontConfigUseDirectImplementation();
   }
 
   return true;