Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NativeFileSystem] must reject in sandboxed windows #20188

Merged
merged 1 commit into from Nov 14, 2019

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Nov 8, 2019

Updates FileSystemDirectoryHandle.getSystemDirectory() and
chooseFileSystemEntries() to reject with a SecurityError
when called by a sandboxed window.

This change also adds a WPT test that accesses the NativeFileSystem from
opaque origins. The test includes a data URI iframe, sandboxed iframe
and a sandboxed opened window. Unlike sandboxed iframes, for data URI
iframes, the NativeFileSystem API is undefined because data URI iframes
do not provide a secure context.

This change gives the NativeFileSystem the same behavior as other web
platform storage with write operations. LocalStorage, indexedDB, and
cacheStorage all fail with SecurityErrors when accessed from a sandbox.
However, sandboxes can read files using <input type=file> and
drag&drop. In the future, if a read-only sandbox scenario emerges, we
can consider loosening this policy for the NativeFileSystem.

Bug: 1014248
Change-Id: Ibeafcdbf102275f2cd45f3cd7dbd8ed592c850c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1907278
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Olivier Yiptong <oyiptong@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Steve Becker <stevebe@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#715119}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot changed the title [NativeFileSystem] getSystemDirectory() must reject in sandboxed windows [NativeFileSystem] must reject in sandboxed windows Nov 9, 2019
Updates FileSystemDirectoryHandle.getSystemDirectory() and
chooseFileSystemEntries() to reject with a SecurityError
when called by a sandboxed window.

This change also adds a WPT test that accesses the NativeFileSystem from
opaque origins.  The test includes a data URI iframe, sandboxed iframe
and a sandboxed opened window.  Unlike sandboxed iframes, for data URI
iframes, the NativeFileSystem API is undefined because data URI iframes
do not provide a secure context.

This change gives the NativeFileSystem the same behavior as other web
platform storage with write operations.  LocalStorage, indexedDB, and
cacheStorage all fail with SecurityErrors when accessed from a sandbox.
However, sandboxes can read files using <input type=file> and
drag&drop.  In the future, if a read-only sandbox scenario emerges, we
can consider loosening this policy for the NativeFileSystem.

Bug: 1014248
Change-Id: Ibeafcdbf102275f2cd45f3cd7dbd8ed592c850c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1907278
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Olivier Yiptong <oyiptong@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Steve Becker <stevebe@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#715119}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants