[PPAPI] It is now possible to pass filesystems from JavaScript to NaCl modules.

ppapi/proxy/ppapi_messages.h

Index: ppapi/proxy/ppapi_messages.h
diff --git a/ppapi/proxy/ppapi_messages.h b/ppapi/proxy/ppapi_messages.h
index 02c4d84c51702254c5f6c2b8f3ac3dbc22a690a2..2313cf7074982b3b3c0d260d2fc5f51442f94473 100644
--- a/ppapi/proxy/ppapi_messages.h
+++ b/ppapi/proxy/ppapi_messages.h
@@ -1291,6 +1291,16 @@ IPC_MESSAGE_CONTROL0(PpapiPluginMsg_FileSystem_OpenReply)
 IPC_MESSAGE_CONTROL1(PpapiHostMsg_FileSystem_InitIsolatedFileSystem,
                      std::string /* fsid */)
 IPC_MESSAGE_CONTROL0(PpapiPluginMsg_FileSystem_InitIsolatedFileSystemReply)
+// Passed from renderer to browser. Creates an already-open file system with a
+// given |root_url| and |file_system_type|.
+IPC_MESSAGE_CONTROL2(PpapiHostMsg_FileSystem_CreateFromRenderer,
+                     std::string /* root_url */,

[Tom Sepez, 2013/10/24 23:02:43]

How does the browser know if the renderer has permission to create a file system
at the specific root_url? It can't just trust that the renderer isn't lying.

[Matt Giuca, 2013/10/25 00:55:14]

I don't really know the answer to this. I thought that there was a security
sandbox between the renderer and the browser, such that the browser would only
let the renderer access files that it had explicitly opened. Or are we now
subverting this sandbox by directly opening a file system in the browser?

I don't fully understand the security model here. Adding teravest and kinuko who
have a better understanding of file system stuff. Can one of you let me know if
what I am doing here is OK from a security standpoint? In particular, look at
this file and pepper_renderer_connection.cc.

[kinuko, 2013/10/25 05:43:02]

Arbitrarily creating a filesystem object with some root url should be relatively
safe, or it'd provide the same level of security we do today for regular Web
sites.  Details are below:

If the root_url points to sandbox filesystems (e.g. Temporary or Persistent)
browser just allows the renderer (and its plugins) to access its own origin's
filesystem.  If renderer or plugin is compromised there's a chance that it may
be able to access other origin's filesystem (but should never be able to access
system files etc).

If the root_url points to Isolated filesystem its filesystem ID is checked in
the browser process so if the renderer (or its plugins) don't have permission to
access the ID the succeeding requests should just fail.

External filesystem in Pepper is a bit special but in general it's also
protected by ChildProcessSecurityPolicy in the browser process (and this patch
doesn't seem to enable it for external fs)

+                     PP_FileSystemType /* file_system_type */)
+// Nested within a ResourceVar for file systems being passed from the renderer
+// to the plugin. Creates an already-open file system resource on the plugin,
+// linked to the existing resource host given in the ResourceVar.
+IPC_MESSAGE_CONTROL1(PpapiPluginMsg_FileSystem_CreateFromPendingHost,
+                     PP_FileSystemType /* file_system_type */)
 
 // Flash DRM ------------------------------------------------------------------
 IPC_MESSAGE_CONTROL0(PpapiHostMsg_FlashDRM_Create)