Open Bug 1580619 Opened 5 months ago Updated 2 months ago

Fix usage of nsIDocShellTreeItem in nsDocShell::GetInheritedPrincipal

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

Fission Milestone M6

People

(Reporter: djvj, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [rm-docshell-tree-item:validate])

https://searchfox.org/mozilla-central/rev/a777ff11b6d700a698c61e5bd17e73b044304494/docshell/base/nsDocShell.cpp#9694

I spent a while on this - mostly digging into what the semantics of principal inheritance are and when it happens.

So this method might reach into the parent docshell via the nsIDocShellTreeItem api and get the internal document, and obtain a principal from that document to return.

This object (nsIPrincipal) obviously cannot cross process boundaries. This cannot be handled by some IPC as the principal object itself is returned, saved, and used directly by the caller (along certain codepaths).

Further reading into the semantics of principals seems to indicate that inheriting principals should only happen between documents which should already been in the same process due to sharing a security context (implied by the ability to inherit principals).

If that's true, then this code should be basically correct already: we don't want to consider out-of-process parents.

Nika: Is the above assessment accurate?

Flags: needinfo?(nika)

Yup - sounds about correct. We should probably change it to explicitly use BrowsingContext, but principal inheritance for OOP iframes is handled through a separate mechanism.

Flags: needinfo?(nika)
Fission Milestone: --- → M5
Priority: -- → P2
Whiteboard: [rm-docshell-tree-item:validate]
Fission Milestone: M5 → Future

Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).

Fission Milestone: Future → M6
You need to log in before you can comment on or make changes to this bug.