To fix the cross-site post submission bug.

content/browser/web_contents/render_view_host_manager.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/browser/web_contents/render_view_host_manager.h"
 
 #include <utility>
 
 #include "base/command_line.h"
 #include "base/logging.h"
+#include "content/browser/child_process_security_policy_impl.h"
 #include "content/browser/debugger/devtools_manager_impl.h"
 #include "content/browser/renderer_host/render_process_host_impl.h"
 #include "content/browser/renderer_host/render_view_host_factory.h"
 #include "content/browser/renderer_host/render_view_host_impl.h"
 #include "content/browser/site_instance_impl.h"
 #include "content/browser/web_contents/navigation_controller_impl.h"
 #include "content/browser/web_contents/navigation_entry_impl.h"
 #include "content/browser/webui/web_ui_impl.h"
 #include "content/common/view_messages.h"
 #include "content/port/browser/render_widget_host_view_port.h"
@@ skipping 818 matching lines @@
         // handlers if the current RVH isn't live.)
         CommitPending();
         return render_view_host_;
       } else {
         NOTREACHED();
         return render_view_host_;
       }
     }
     // Otherwise, it's safe to treat this as a pending cross-site transition.
 
+  
+  if (entry.GetHasPostData()) {
+    ChildProcessSecurityPolicyImpl* policy =

[michaeln, 2012/10/23 23:22:18]

Is the 'policy' thread safe? Just checking because i think this smart collection
class gets accessed on the IO thread too. And if it is thread safe, any chance
for raciness around when access is granted to the 'old' compared to when we're
checking to migrate access to the 'new'?

[irobert, 2012/11/01 19:26:31]

Not quite sure about it. But i do believe this could be problem. I will further
dig into it.

On 2012/10/23 23:22:18, michaeln wrote:

[Charlie Reis, 2012/11/05 16:21:40]

From the header file:
"ChildProcessSecurityPolicy is a singleton that may be used on any thread."

I haven't looked closely enough to tell whether a race between granting and
checking is possible, though.

[irobert, 2012/11/05 17:26:52]

I have verified this with Darin. He mentioned: "It is a thread-safe class. 
However, you do need to consider sequencing.  You need to grant permission
before the renderer process issues the POST request." 

On 2012/11/05 16:21:40, creis wrote:

+        ChildProcessSecurityPolicyImpl::GetInstance();
+    int oldID = render_view_host_->GetSiteInstance()->GetProcess()->GetID();
+    int newID = pending_render_view_host_->GetSiteInstance()->GetProcess()->GetID();
+    std::vector<content::WebHTTPPOSTBodyParams> post_data = entry.post_data;
+    for (std::vector<content::WebHTTPPOSTBodyParams>::iterator it=post_data.begin();
+         it < post_data.end(); it++) {
+      if ((*it).type == content::WebHTTPPOSTBodyParams::TypeFile) {
+        FilePath file = FilePath((*it).filePath);
+        if (policy->CanReadFile(oldID, file)) {
+          policy->GrantReadFile(newID, file);
+        }
+      }
+    }
+  }
+
     // Make sure the old render view stops, in case a load is in progress.
     render_view_host_->Send(
         new ViewMsg_Stop(render_view_host_->GetRoutingID()));
 
     // Suspend the new render view (i.e., don't let it send the cross-site
     // Navigate message) until we hear back from the old renderer's
     // onbeforeunload handler.  If the handler returns false, we'll have to
     // cancel the request.
     DCHECK(!pending_render_view_host_->are_navigations_suspended());
     pending_render_view_host_->SetNavigationsSuspended(true);
@@ skipping 108 matching lines @@
 }
 
 RenderViewHostImpl* RenderViewHostManager::GetSwappedOutRenderViewHost(
     SiteInstance* instance) {
   RenderViewHostMap::iterator iter = swapped_out_hosts_.find(instance->GetId());
   if (iter != swapped_out_hosts_.end())
     return iter->second;
 
   return NULL;
 }