1378377 - file:// URI sub-resources within CAPS whitelisted http pages will fail to load with read sandboxing

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, enhancement)

Description

[Bob Owen (:bobowen) PTO until 8th Oct]

If http pages that are allowed to use file:// URIs (via the capability.policy.* prefs) use them as sub-resources, these will fail to load when file read permissions are removed from web content process.

The proposed solution is to run these whitelisted domains in the file content process.

Comment 1

[Bob Owen (:bobowen) PTO until 8th Oct]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8026bfe24c0171d50dc9edb2829f12df40c4cdf2
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e7360535e778157fb8c65894ce0bd3c59622219a

The Windows 10 jobs seem to be broken on a lot of recent try pushes.

Comment 2

[Bob Owen (:bobowen) PTO until 8th Oct]

Attachment: Part 1: Expose file:// URI whitelist check to chrome JS

This is required so that we can check the whitelist and run domains that are
allowed to use file:// URIs in the file content process.

Comment 3

[Bob Owen (:bobowen) PTO until 8th Oct]

Attachment: Part 2: Run file://URI whitelisted domains in a file content process

Comment 4

[Bob Owen (:bobowen) PTO until 8th Oct]

Attachment: Part 3: Make sure domains whitelisted for file:// URI use run in file contest process

Comment 5

[:Gijs (he/him)]

Comment on attachment 8886945 [details] [diff] [review]
Part 2: Run file://URI whitelisted domains in a file content process

Review of attachment 8886945 [details] [diff] [review]:
-----------------------------------------------------------------

r=me but please make sure the question below gets answered either in the code comments, or on the bug, or by changing the patch. :-)

::: browser/modules/E10SUtils.jsm
@@ +51,5 @@
>      return WEB_REMOTE_TYPE;
>    }
>  
> +  // If the domain is whitelisted to allow it to use file:// URIs, then we have
> +  // to run it in a file content process, in case it uses file:// sub-resources.

Shouldn't this check come before the !aPreferredRemoteType default-to-web-process?

Comment 6

[Bob Owen (:bobowen) PTO until 8th Oct]

(In reply to :Gijs from comment #5)
...
> > +  // If the domain is whitelisted to allow it to use file:// URIs, then we have
> > +  // to run it in a file content process, in case it uses file:// sub-resources.
> 
> Shouldn't this check come before the !aPreferredRemoteType
> default-to-web-process?

You're right it should, the current code happens to work when navigating from a parent run page because the web remote type gets thrown out by a check in the child.
Then as the preferred remote type is web for the next check in the parent we finally get to the correct file remote type.

However, we obviously don't want to go through that rigmarole, changed locally, thanks. :-)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8886944 [details] [diff] [review]
Part 1: Expose file:// URI whitelist check to chrome JS

r=me

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b4f4996c541e
Part 1: Expose file:// URI whitelist check to chrome JS. r=bz
https://hg.mozilla.org/integration/mozilla-inbound/rev/137cb6b5df67
Part 2: Run file://URI whitelisted domains in a file content process. r=Gijs
https://hg.mozilla.org/integration/mozilla-inbound/rev/078a6b523cc1
Part 3: Make sure domains whitelisted for file:// URI use run in file contest process. r=Gijs

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b4f4996c541e
https://hg.mozilla.org/mozilla-central/rev/137cb6b5df67
https://hg.mozilla.org/mozilla-central/rev/078a6b523cc1