Closed Bug 1378377 Opened 2 years ago Closed 2 years ago

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

Categories

(Core :: DOM: Content Processes, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: bobowen, Assigned: bobowen)

References

Details

(Whiteboard: sbwc2, sbmc2, sblc3)

Attachments

(3 files)

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.
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.
Attachment #8886944 - Flags: review?(bzbarsky)
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?
Attachment #8886945 - Flags: review?(gijskruitbosch+bugs) → review+
Attachment #8886946 - Flags: review?(gijskruitbosch+bugs) → review+
(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 on attachment 8886944 [details] [diff] [review]
Part 1: Expose file:// URI whitelist check to chrome JS

r=me
Attachment #8886944 - Flags: review?(bzbarsky) → review+
Pushed by bobowencode@gmail.com:
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
You need to log in before you can comment on or make changes to this bug.