1,234
edits
Changes
no edit summary
I'd like to pin down exactly what our security model for resource: is, then implement that model.
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
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
