diff options
author | mtomasz@chromium.org <mtomasz@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-02-26 04:56:40 +0000 |
---|---|---|
committer | mtomasz@chromium.org <mtomasz@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-02-26 04:56:40 +0000 |
commit | 0fa422a0e4ee63132825a23a2f60f1a0c05aec79 (patch) | |
tree | 74b2cfb7115484e507cde71b18d1e9ea4e1a1c47 /webkit/browser/fileapi/sandbox_file_system_backend.cc | |
parent | 7c89ff265392829fbc3510c047a555d290366408 (diff) | |
download | chromium_src-0fa422a0e4ee63132825a23a2f60f1a0c05aec79.zip chromium_src-0fa422a0e4ee63132825a23a2f60f1a0c05aec79.tar.gz chromium_src-0fa422a0e4ee63132825a23a2f60f1a0c05aec79.tar.bz2 |
Create file systems restricted to volumes.
Before, on Chrome OS, JS Entry objects were holding the same DOMFileSystem
object, and they were attached to the same big root. All of the mount points
were first-level directories. This looks like a Linux approach.
However, for better isolation a different approach has been suggested. To have
a separate DOMFileSystem object per every volume on Chrome OS. So, Downloads
and Drive files would be separate, and the filesystem's root would be one of
the mount points.
What is more, restricting DOMFileSystem objects to a mount point is not enough.
In case of `archive` and `removable`, we have two level mount points. The first
level is either `archive` or `removable`. Either of them contains mounted
volumes - archives or removable devices.
This patch restricts DOMFileSystem objects (and thereof Entry objects) to the
inner most mount point. For example: /Downloads, /drive, /archive/archive-1,
/archive/archive-2, /removable/disk-1, /removable/disk-2.
Having this solution it is impossible to access the grand root containing all
of the outer mount points, which was until now restricted in JavaScript. Also,
it doesn't allow to get an Entry for /archive and /removable, which was also
filtered out in JS layer.
Moreover, and what is the most important, this approach allows to map a C++
VolumeInfo to a DOMFileSystem object with 1:1 relationship.
To achieve that, the OpenFileSystem has been renamed to ResolveURL, since this
method has been always used to Resolving a file system URL. Opening the file
system was a side effect. This allowed to unify the code paths for sandboxed
and non-sandboxed file systems. Before, for non-sandboxed file systems, the
root url (and the name) were manually computed using a deprecated utility
function fileapi::GetFileSystemInfoForChromeOS(), which is removed in this
patch.
The drawback of this change was that the root_url and the fs name resolution
became asynchonous. The reason for that is that sandboxed file systems may
perform operations on different threads, therefore they have to be
asynchronous. To simplify migration a utility function has been introduced to
convert FileDefinition vectors to EntryDefinition vectors.
Finally, this change will allow simplifying Files app volumes logic
significantly. The JS VolumeInfo will match C++ VolumeInfo 1:1, as well as
either VolumeInfo will match a DOMFileSystem object 1:1. As a result, we will
be able to remove special cases for inner mount points (for archives and
removables). Another advantage is simple way to pass names of JS-provided file
systems.
The permission management is currently simplified, but the next step will be to
grant permissions per inner-most mount point, which will clean up security
policy comparing to the former implementation.
TBR=phajdan.jr@chromium.org
BUG=318021
TEST=Tested manually.
Review URL: https://codereview.chromium.org/162963003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253351 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/browser/fileapi/sandbox_file_system_backend.cc')
-rw-r--r-- | webkit/browser/fileapi/sandbox_file_system_backend.cc | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/webkit/browser/fileapi/sandbox_file_system_backend.cc b/webkit/browser/fileapi/sandbox_file_system_backend.cc index 62f91de..cb288aa 100644 --- a/webkit/browser/fileapi/sandbox_file_system_backend.cc +++ b/webkit/browser/fileapi/sandbox_file_system_backend.cc @@ -60,24 +60,25 @@ void SandboxFileSystemBackend::Initialize(FileSystemContext* context) { delegate_->quota_observer(), NULL); } -void SandboxFileSystemBackend::OpenFileSystem( - const GURL& origin_url, - fileapi::FileSystemType type, +void SandboxFileSystemBackend::ResolveURL( + const FileSystemURL& url, OpenFileSystemMode mode, const OpenFileSystemCallback& callback) { - DCHECK(CanHandleType(type)); + DCHECK(CanHandleType(url.type())); DCHECK(delegate_); if (delegate_->file_system_options().is_incognito() && - !(type == kFileSystemTypeTemporary && + !(url.type() == kFileSystemTypeTemporary && enable_temporary_file_system_in_incognito_)) { // TODO(kinuko): return an isolated temporary directory. callback.Run(GURL(), std::string(), base::File::FILE_ERROR_SECURITY); return; } - delegate_->OpenFileSystem( - origin_url, type, mode, callback, - GetFileSystemRootURI(origin_url, type)); + delegate_->OpenFileSystem(url.origin(), + url.type(), + mode, + callback, + GetFileSystemRootURI(url.origin(), url.type())); } AsyncFileUtil* SandboxFileSystemBackend::GetAsyncFileUtil( |