Closed Bug 1288874 Opened 4 years ago Closed 3 years ago

Decide on our story for file access from add-ons, post-sandboxing


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




Tracking Status
firefox50 --- affected


(Reporter: jld, Unassigned)


(Depends on 1 open bug, )


(Keywords: meta)

Add-ons sometimes need to access files — at least for reading — from content processes.  Their own resources are in known locations and relatively easy to deal with, but there are also cases where the access would be of a file specified by the user, which could be anywhere.  We've already run into problems when the Mac sandbox banned access to ~/Library with exceptions for non-sensitive parts of the Firefox profile.

We should decide what we're doing about this.  Some considerations include:

* Workarounds that require reading files into memory, copying the contents into each process, and/or using data: URLs are often simple but are undesireable for memory usage reasons.

* There are Gecko APIs that are not URL-scheme-agnostic (yet?).  Later comments on bug 1221148 are about mozIJSSubScriptLoader, which insists on file:// or chrome:// (and I haven't looked at the code enough to know whether it would accept a chrome:// that expands to something that isn't ultimately a file://).

* Changing how chrome:// and resource:// (and moz-extension://) URLs work, so that content processes expand them into something that messages the parent for the actual open, is proposed in bug 1109293 and bug 1136836.

* File objects and createObjectURL should already be able to handle most of this — especially now that bug 1279186 landed, so APIs that just send URL specs to other processes and expect them to work (e.g., the stylesheet service as seen in bug 1187099, or even the current implementation of chrome:// and resource://) should now be usable.  A remote File is essentially a reusable capability for opening a particular filesystem path read-only, which is usually what's wanted.  But there's mozIJSSubScriptLoader, mentioned above, and there could be other blob-refusing APIs I haven't heard about yet.

* There's also bug 922481, which proposed changing the file:// handler to always have the parent process do the open.  This is… probably not too useful, because the parent side of the file:// remoting service has to implement its own “sandbox policy” on the paths requested — the content process will be able to access the union of that and the system-level sandbox policy — which means access grants would have to be registered somehow.  And that's a facility we already have implemented in the form of remote blobs (and a more powerful interface, minus the implementation, as the chrome/resource/moz-extension registries — they can map entire subtrees, not just individual files).
needinfo?(billm), who's had ideas about this kind of thing in the past and has been working on WebExtensions.
Flags: needinfo?(wmccloskey)
Keywords: meta
I'm not sure what I can add here. WebExtensions are a pretty easy case. They need to be able to access moz-extension URIs, but that's it.

I don't really have an opinion on how we should handle chrome, resource, and moz-extension URIs. As long as they work, any solution seems fine.

Bug 1221148 is a little different. It's an add-on that wants to directly access files in the profile from the content process. In my opinion, that should be WONTFIX. If Firefox can do without file system access, I don't see why add-ons should require it.
Flags: needinfo?(wmccloskey)
i'm adding the add-ons team to this bug =].  Looking for time for us to talk this week, as we cannot release sandboxing without evaluating the add-ons impact.  From Bug 1221148 the impact from one issue is potentially quite broad.  We will look into more specific impact details, but we're not talking dozens... it's hundreds to thousands of add-ons (including at least Greasemonkey with 1m+ users).

Sounds like Jed outlined a good place to start on topics and what bugs could mitigate versus what guidance to give developers.  

I'll work on timing coordination aspect - to minimize breaking users and add-ons in new ways each release for the next 6 months.

Goal:  determine impact, mitigation, what can't be mitigated.  reasonable time to address that coordinates "this will break these scenarios in ___ release (based on Beta progress), and here's what should be done".
Blocks: e10s-addons
Priority: -- → P1
We are going to set a hard limit on file access from the content process: don't do it, it will won't work, or will break later.

To prep for this, we will create a new MDN doc specific to sandboxing issues off the main e10s page [1].

Included in this doc:

- Document the general policy
- Move the file access blurb under limitations of frame scripts doc [2] into this new document.
- Update any references we can find about file access issues caused by sandboxing in other MDN docs to point to this new doc.
- Document debugging features for logging sandbox restrictions.
- Document example apis that won't work and explain why.
- Document existing apis developers can use to work around file access issues. 

(In reply to Jim Mathies [:jimm] from comment #4)
> We are going to set a hard limit on file access from the content process:
> don't do it, it will won't work, or will break later.

"don't do it, it won't work, or will break later."
Going to close this, as describes, starting with 57 we'll be web extensions only, and until then we'll continue our work on sandboxing which may impact some addons.
Closed: 3 years ago
Resolution: --- → FIXED
No longer depends on: 922481
You need to log in before you can comment on or make changes to this bug.