Difference between revisions of "Mdssummary22sept"

From CDOT Wiki
Jump to: navigation, search
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
I'd like to pin down exactly what our security model for resource: is, then implement that model.
+
One post this week, Boris Zbarsky gives a summary the current setup for CheckLoadURI (which type of security principal can load what) and asks for comments about whether that is the desired behaviour. No replies.
 
 
Right now, we treat resource: as equivalent to file: in some cases (nsScriptSecurityManager::CheckLoadURIFromScript) and equivalent to chrome: (not to be confused with "system principal" here!) in other cases (nsScriptSecurityManager::CheckLoadURIWithPrincipal, various XBL code).
 
 
 
In brief, the current setup for CheckLoadURI is:
 
 
 
1)  System principal can load anything.
 
 
 
2) Anything that has nsIScriptSecurityManager::ALLOW_CHROME set can load chrome: and resource: (but not file:), no matter what the origin principal. This flag is set for stylesheet, xbl binding, image, and script loads.
 
 
 
3)  A non-system principal with a chrome: or resource: codebase is allowed to load file:, chrome:, and resource: URIs.
 
 
 
4)  file: URIs are not allowed to load resource: or chrome: URIs, modulo item 2.
 
 
 
5)  Any principal that has UniversalFileRead can load file: and resource: URIs, but not chrome:.
 
 
 
The question is what behavior we actually want.  For example, given the chrome: protocol handler changes to give all content chrome: channels a system principal, non-system chrome: basically means "skin". How does that affect the above setup, if at all?
 
 
 
I'd welcome any clarifications here.
 
 
 
-Boris
 

Latest revision as of 21:50, 28 September 2006

One post this week, Boris Zbarsky gives a summary the current setup for CheckLoadURI (which type of security principal can load what) and asks for comments about whether that is the desired behaviour. No replies.