Launches a privileged utility process.

chrome/service/service_utility_process_host.cc

Index: chrome/service/service_utility_process_host.cc
diff --git a/chrome/service/service_utility_process_host.cc b/chrome/service/service_utility_process_host.cc
index de55b4b7dc89c17101696db1a93712e5c2ab76a9..37ad943020b3531e7742f46f808b705076740c48 100644
--- a/chrome/service/service_utility_process_host.cc
+++ b/chrome/service/service_utility_process_host.cc
@@ -50,7 +50,7 @@ class ServiceSandboxedProcessLauncherDelegate
  private:
   base::FilePath exposed_dir_;
 };
-}
+} // namespace
 
 #endif  // OS_WIN
 
@@ -206,6 +206,10 @@ bool ServiceUtilityProcessHost::OnMessageReceived(const IPC::Message& message) {
   return handled;
 }
 
+base::ProcessHandle ServiceUtilityProcessHost::GetHandle() const {
+  return handle_;

[jam, 2014/01/24 22:14:03]

I see where you call this, but it's not clear to me why this is needed?

[Drew Haven, 2014/01/27 21:43:51]

It's because when I ran the elevated process I found that
OpenPrivilegedProcessHandle was failing.  We already have a handle, but not the
PID from ShellExecuteEx.  I couldn't find a way to get the process ID associated
with a handle without doing some complicated code execution in the context of
the other process.  As such, I just put in a way to directly get the handle we
already had instead of going back through the process ID.

I'm just going on what I could find through MSDN documentation and searches
though.  I could be wrong.

[jam, 2014/01/27 21:55:45]

I may be missing something. you say you already have a handle but not the pid.
do you mean the reverse? the caller is ChildProcessHostImpl::OnChannelConnected
which has a peer_pid.

+}
+
 void ServiceUtilityProcessHost::OnRenderPDFPagesToMetafileSucceeded(
     int highest_rendered_page_number,
     double scale_factor) {