|
|
| 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 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
| |
Revision as of 22:41, 28 September 2006
One post this week, Boris Zbarsky gives a summary the current setup for CheckLoadURI and asks for comments about whether that is the desired behaviour. No replies.
