linux: use /proc/self/exe when exec'ing ourselves

We don't want to ever go out to disk when looking for data after
startup, since they can be changed by an update.

We *should* just be using the zygote, but the zygote is sandboxed-only
for now, and fixing that has a lengthy dependency graph.  In the
interim, /proc/self/exe is the correct executable and exec'ing it should
work as long as the subprocess doesn't need any other files from the
Chrome directory.

BUG=22703
TEST=Start Chrome.  Move away the entire Chrome directory; plugins
should still work.

Review URL: http://codereview.chromium.org/403018

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

3 files changed, 17 insertions, 10 deletions

diff --git a/chrome/common/child_process_host.cc b/chrome/common/child_process_host.cc
index d4a9eda..2e0f1f6 100644
--- a/chrome/common/child_process_host.cc
+++ b/chrome/common/child_process_host.cc
@@ -93,16 +93,20 @@ FilePath ChildProcessHost::GetChildPath() {
   if (!child_path.empty())
     return child_path;
 
-#if !defined(OS_MACOSX)
-  // On most platforms, the child executable is the same as the current
-  // executable.
-  PathService::Get(base::FILE_EXE, &child_path);
-#else
+#if defined(OS_LINUX)
+  // Use /proc/self/exe rather than our known binary path so updates
+  // can't swap out the binary from underneath us.
+  child_path = FilePath("/proc/self/exe");
+#elif defined(OS_MACOSX)
   // On the Mac, the child executable lives at a predefined location within
   // the app bundle's versioned directory.
   child_path = chrome::GetVersionedDirectory().
       Append(chrome::kHelperProcessExecutablePath);
-#endif  // OS_MACOSX
+#else
+  // On most platforms, the child executable is the same as the current
+  // executable.
+  PathService::Get(base::FILE_EXE, &child_path);
+#endif
 
   return child_path;
 }
diff --git a/chrome/common/chrome_constants.cc b/chrome/common/chrome_constants.cc
index 1226fe5..81d03ea 100644
--- a/chrome/common/chrome_constants.cc
+++ b/chrome/common/chrome_constants.cc
@@ -29,7 +29,9 @@ const wchar_t kBrowserProcessExecutableName[] = L"chrome.exe";
 const wchar_t kHelperProcessExecutableName[] = L"chrome.exe";
 #elif defined(OS_LINUX)
 const wchar_t kBrowserProcessExecutableName[] = L"chrome";
-const wchar_t kHelperProcessExecutableName[] = L"chrome";
+// Helper processes end up with a name of "exe" due to execing via
+// /proc/self/exe.  See bug 22703.
+const wchar_t kHelperProcessExecutableName[] = L"exe";
 #elif defined(OS_MACOSX)
 const wchar_t kBrowserProcessExecutableName[] = PRODUCT_STRING_W;
 const wchar_t kHelperProcessExecutableName[] = PRODUCT_STRING_W L" Helper";
diff --git a/chrome/test/chrome_process_util.cc b/chrome/test/chrome_process_util.cc
index f53cbbd..fea1d0e 100644
--- a/chrome/test/chrome_process_util.cc
+++ b/chrome/test/chrome_process_util.cc
@@ -100,9 +100,10 @@ ChromeProcessList GetRunningChromeProcesses(const FilePath& data_dir) {
   }
 #endif  // defined(OS_LINUX)
 
-#if defined(OS_MACOSX)
-  // On Mac OS X we run the subprocesses with a different bundle, so they end
-  // up with a different name, so we have to collect them in a second pass.
+#if defined(OS_LINUX) || defined(OS_MACOSX)
+  // On Mac OS X we run the subprocesses with a different bundle, and
+  // on Linux via /proc/self/exe, so they end up with a different
+  // name.  We must collect them in a second pass.
   {
     ChildProcessFilter filter(browser_pid);
     base::NamedProcessIterator it(chrome::kHelperProcessExecutableName,