[mojo] Use a pipe path to initialise Mojo in elevated utility processes.

content/child/child_thread_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/child/child_thread_impl.h"
 
 #include <signal.h>
 #include <string>
 #include <utility>
 
@@ skipping 49 matching lines @@
 #include "ipc/attachment_broker.h"
 #include "ipc/attachment_broker_unprivileged.h"
 #include "ipc/ipc_logging.h"
 #include "ipc/ipc_platform_file.h"
 #include "ipc/ipc_switches.h"
 #include "ipc/ipc_sync_channel.h"
 #include "ipc/ipc_sync_message_filter.h"
 #include "ipc/mojo/ipc_channel_mojo.h"
 #include "ipc/mojo/scoped_ipc_support.h"
 #include "mojo/edk/embedder/embedder.h"
+#include "mojo/edk/embedder/named_platform_channel_pair.h"
 #include "mojo/edk/embedder/platform_channel_pair.h"
 
 #if defined(OS_POSIX)
 #include "base/posix/global_descriptors.h"
 #include "content/public/common/content_descriptors.h"
 #endif
 
 using tracked_objects::ThreadData;
 
 namespace content {
@@ skipping 142 matching lines @@
 
   closure_.Run();
 }
 
 base::LazyInstance<QuitClosure> g_quit_closure = LAZY_INSTANCE_INITIALIZER;
 #endif
 
 void InitializeMojoIPCChannel() {
   mojo::edk::ScopedPlatformHandle platform_channel;
 #if defined(OS_WIN)
-  platform_channel =
-      mojo::edk::PlatformChannelPair::PassClientHandleFromParentProcess(
-          *base::CommandLine::ForCurrentProcess());
+  if (base::CommandLine::ForCurrentProcess()->HasSwitch(
+      mojo::edk::PlatformChannelPair::kMojoPlatformChannelHandleSwitch)) {

[ncarter (slow), 2016/05/11 00:14:23]

The layering here feels little awkward -- content has to poll for the presence
of a mojo-edk switch, to know which mojo-edk function to call?

Would this be cleaner if it were just be a content switch, and we pass the
string value on to the mojo edk function?

[Anand Mistry (off Chromium), 2016/05/11 04:15:20]

Hm. I agree that the switch should be moved to content instead of being part of
Mojo, but this code follows the existing pattern in
mojo::edk::PlatformChannelPair and I'd like to keep the two consistent. But even
with that, this should still be two different function calls. The fact we have a
named pipe should be a very explicit choice.

So my question is, can this change be submitted with the expectation that this
(and PlatformChannelPair) is cleaned up soon after. Or do you want me to do the
clean up first so this CL follows a cleaned up pattern?

[ncarter (slow), 2016/05/11 16:06:07]

Follow-on CL is totally fine.

+    platform_channel =
+        mojo::edk::PlatformChannelPair::PassClientHandleFromParentProcess(
+            *base::CommandLine::ForCurrentProcess());
+  } else {
+    // If this process is elevated, it will have a pipe path passed on the
+    // command line.
+    platform_channel =
+        mojo::edk::NamedPlatformChannelPair::PassClientHandleFromParentProcess(
+            *base::CommandLine::ForCurrentProcess());
+  }
 #elif defined(OS_POSIX)
   platform_channel.reset(mojo::edk::PlatformHandle(
       base::GlobalDescriptors::GetInstance()->Get(kMojoIPCChannel)));
 #endif
   // Mojo isn't supported on all child process types.
   // TODO(crbug.com/604282): Support Mojo in the remaining processes.
   if (!platform_channel.is_valid())
     return;
   mojo::edk::SetParentPipeHandle(std::move(platform_channel));
 }
@@ skipping 476 matching lines @@
 void ChildThreadImpl::EnsureConnected() {
   VLOG(0) << "ChildThreadImpl::EnsureConnected()";
   base::Process::Current().Terminate(0, false);
 }
 
 bool ChildThreadImpl::IsInBrowserProcess() const {
   return browser_process_io_runner_;
 }
 
 }  // namespace content