1388922 - browser_content_sandbox_fs.js fails to detect $PROFILE/extensions not readable on Linux

Status: REOPENED

(Core :: Security: Process Sandboxing, defect, P3)

Description

[Haik Aftandilian [:haik]]

The test in browser_content_sandbox_fs.js that makes sure $PROFILE/extensions is readable should have caught bug 1385891 "Firefox doesn't load extension's files after upgrade" which was a problem caused by the Linux sandbox not allowing read access to $PROFILE/extensions. This bug is to fix the test.

Comment 1

[Haik Aftandilian [:haik]]

On Mac, the test works correctly. When the sandbox doesn't allow reading of $PROFILE/extensions, iterating over the directory entries throws an exception with an error message such as "Unix error 1 during operation DirectoryIterator on file /var/folders/46/.../T/tmp0w6osF.mozrunner/extensions (Operation not permitted)". Will test on Linux.

Comment 2

[Haik Aftandilian [:haik]]

Bug 1385891 wasn't detected by automated testing because, on Linux, $PROFILE/extensions ends up in /tmp. For example, "/tmp/tmp4APB8w.mozrunner/extensions". Since our Linux sandbox whitelists /tmp, it allows everything in the profile to be readable. Even though the sandbox rule to allow $PROFILE/extensions to be readable was not present, the directory was readable in automated tests because of the rule to allow /tmp. This should have been obvious because we are already disabling some tests in this file on Linux due to this issue.

And we already have bug 1386404 - "Stop allowing Linux content processes to access /tmp" which would allow the test to work as expected. Closing this as a dupe of 1386404.

Alternatively, we could change the sandbox implementation to allow /tmp, but deny /tmp/<profile>. Will discuss with sandboxing peers.

Comment 3

[Haik Aftandilian [:haik]]

Re-opening the bug. Discussed this at our sandboxing standup today. We may be able to workaround the /tmp issue so that the profile-related checks in browser_content_sandbox_fs.js can be made to work on Linux.