1036656 - CAPS legacy compatibility replacement for local links linking permissions is not actually backward compatible

Status: RESOLVED DUPLICATE of bug 1053725

(Core :: Security: CAPS, defect)

Description

[Giorgio Maone [:ma1]]

This work-around fails to properly emulate the policy.sites syntax for hostnames only (without protocol).
Specifically, up to ESR 24 you could specify

user_pref("capability.policy.mypolicy.sites", "mozilla.org");

and have the policy apply to www.mozilla.org.

Current implementation (Gecko 30 and above) ignores the above syntax (just one hostname), while having a hostname together to with any other entry causes the following error to be spit by the console:

"Unable to add site to file:// URI whitelist: mozilla.org"

Steps to reproduce:

1. Open a chrome-enabled Scratchpad in latest Nightly
2. Open the browser console and watch for chrome-generated error messages
3. Execute the following code in Browser context:
// BEGIN SNIPPET
function p(n, v) Services.prefs.setCharPref(n, v);

p("capability.policy.policynames", "lf");
p("capability.policy.lf.checkloaduri.enabled", "allAccess");
p("capability.policy.lf.sites", "mozilla.com mozilla.org");
content.open("http://www.mozilla.org").addEventListener("load", function(ev) {
  ev.currentTarget.document.body.innerHTML ="<iframe src=file:///></iframe>"
}, false)

// END SNIPPET

* Expected result: no error message is shown in the console as a result of running the code from step #3

* Actual result: the browser console spits out
  Unable to to add site to file:// URI whitelist: mozilla.com
  Unable to to add site to file:// URI whitelist: mozilla.org
  Security Error: Content at http://www.mozilla.org/en-US/ may not load or link to file:///.

As a reference, running the same code in Firefox ESR 24.x doesn't cause any error, and if file:/// is replaced with an actual local filesystem resource it gets loaded in the iframe.

Comment 1

[Bobby Holley (:bholley)]

This basically amounts to wildcarding. See bug 1028321 comment 4. I'd take a patch (with tests) that switched mFileURIWhitelist entries to a struct with a URI and bool inside of it, with the bool indicating that wildcard matching should be performed. We'd probably also need to refactor the logic in nsHTMLDocument::SetDomain into a helper on nsContentUtils (unless something like it exists already).

I'm not likely to write this patch myself.

Comment 2

[Jefferson]

Is this fixed by bug 1053725 ?

Comment 3

[Bobby Holley (:bholley)]

(In reply to Jefferson from comment #2)
> Is this fixed by bug 1053725 ?

I think so, yes. Good catch!

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Bobby Holley (busy) from comment #3)
> (In reply to Jefferson from comment #2)
> > Is this fixed by bug 1053725 ?
> 
> I think so, yes. Good catch!

Resolving this, then.