Closed Bug 1182357 Opened 4 years ago Closed 4 years ago

Add API to allow explicit creation of nsExpandedPrincipals from JS

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: billm, Assigned: bholley)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #1180921 +++
This is a follow-up:

> One thing I think we're missing is a way to create a sandbox with expanded
> principals that uses OriginAttributes. We could just copy the addonId
> argument from the Sandbox constructor to the OriginAttributes of the
> expanded principals. Or we could make a constructor for expanded principals.

Yes, we need this. Please file a followup bug and needinfo me and I'll do it.
Flags: needinfo?(bobbyholley)
(In reply to Bill McCloskey (:billm) from comment #0)
> > One thing I think we're missing is a way to create a sandbox with expanded
> > principals that uses OriginAttributes. We could just copy the addonId

I think there are two cases where we need OriginAttributes, on parent/chrome side with a regular principal (some resource URI or later maybe an addon protocol) and on child/content side with an expanded principal. Can/should we throw for anything else? I'm particularly worried that someone creates a codebase principal in the content process with OriginAttributes. Since we ignore OriginAttribute in the subsumes code that could easily lead to a leak of privileges.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #1)
> Since we ignore OriginAttribute in the subsumes code

We don't ignore it at all: https://hg.mozilla.org/mozilla-central/annotate/e7e69cc8c07b/caps/nsPrincipal.cpp#l169

That's the whole point - each origin attributes makes an orthogonal dimension of origin-ness.
Summary: Implement pattern-based whitelisting mechanism for cross-origin XHR → Add API to allow explicit creation of nsExpandedPrincipals from JS
(In reply to Bobby Holley (:bholley) from comment #2)
> (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #1)
> https://hg.mozilla.org/mozilla-central/annotate/e7e69cc8c07b/caps/
> nsPrincipal.cpp#l169

Bah, I was looking for this exact line but somehow managed to overlook it... I show myself out.
The fact that the caller needs to pass this is just an artifact of the clunky
XPIDL type system. This should let us make nicer APIs.
Attachment #8633858 - Flags: review?(mrbkap)
(In reply to Bobby Holley (:bholley) from comment #7)
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d86fa5e4653c

Looks green. re-running with ASAN just in case.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=928a699ce497
Attachment #8633858 - Flags: review?(mrbkap) → review+
Attachment #8633859 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/mozilla-central/rev/86d4a584905c
https://hg.mozilla.org/mozilla-central/rev/71069116ee28
Assignee: nobody → bobbyholley
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.