388186 - CAPS disregards site policy in recent trunk

Status: RESOLVED INVALID

(Core :: Security: CAPS, defect)

Description

[Joe Sabash [:JoeS1]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060804 Firefox/1.5.0.6 (mahowi)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071312 Thunderbird/3.0a1pre ID:2007071312

Site policies are ignored in recent trunk build of thunderbird

Reproducible: Always

Steps to Reproduce:
1.Create a site policy and place it in a user.js file such as:
user_pref("capability.policy.policynames", "jsok");
user_pref("capability.policy.default.javascript.enabled", "noAccess");
user_pref("capability.policy.jsok.sites", "news://news.mozilla.org news://secnews.netscape.com");
user_pref("capability.policy.jsok.javascript.enabled", "allAccess"); 
2.Expect that all domains would block javascript execution except those named on the "sites" line.
3.Try it.
Actual Results:  
Javascript is blocked for all domains.

Expected Results:  
Javascript should be enabled for all domains listed on the sites line.

Works in recent branch.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070504 Thunderbird/3.0a1 ID:2007050403
works as expected. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071312 Thunderbird/3.0a1pre ID:2007071312
blocks all javascript and does not enable the specified sites.

Comment 1

[Daniel Veditz [:dveditz]]

Is it only that one capability that broke? The changes to caps itself during that interval look totally benign:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcaps&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-05&maxdate=2007-07-13%2012:00&cvsroot=%2Fcvsroot

would it be possible to narrow down the regression range to a single day? I won't be able to do it myself for about a week.

Comment 2

[Joe Sabash [:JoeS1]]

I wouldn't ask someone to help patch my roof, and then refuse to pass the hammer.
Narrowing regression range:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070618 Thunderbird/3.0a1pre ID:2007061803
works as expected

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Thunderbird/3.0a1pre ID:2007061903
Regressed

Comment 3

[Boris Zbarsky [:bzbarsky]]

Not that the query in comment 1 is wrong.  It's going from July 5, whereas the range given was from May 4.

The one-day range in question is:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-18+03&maxdate=2007-06-19+03&cvsroot=%2Fcvsroot

Chances are, this is one of my changes.  I'll be happy to debug if you can point me to a way to test (a newsgroup message to load, in particular).

Comment 4

[Joe Sabash [:JoeS1]]

Happy to provide you with one BZ
news://news.mozilla.org:119/[e-mail]

Comment 5

[Boris Zbarsky [:bzbarsky]]

So... I don't see how this could have possibly worked.  "javascript.allow.mailnews" is false in Thunderbird by default, and that pref overrides security policies: if it's false, no script will run in mailnews, no matter what the domain is....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Although, even if I set "javascript.allow.mailnews" to true, things don't work.  Investigating.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So the origin I'm seeing is news://news.mozilla.org:119 and not news://news.mozilla.org

Comment 8

[Boris Zbarsky [:bzbarsky]]

But that's also been the case for a while now, as I recall.  I seem to recall it coming up in a bug a while back...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yeah, so the port comes from nsNNTPProtocol::Initialize which sets it on the channel's URI; then GetChannelPrincipal ends up with that URI.  I really don't see why this would have regressed in the given range, since I see no changes to nsNNTPProtocol in there either, and GetChannelPrincipal has not changed in a while... ccing mscott and bienvenu, in case they have any ideas.  But double-check the port thing?

Comment 10

[Joe Sabash [:JoeS1]]

OK thanks for looking into this bz,
So in modifying the sites line to include the port like this:
user_pref("capability.policy.jsok.sites", "news://news.mozilla.org:119
news://secnews.netscape.com");
seems to work fine, and I will pass that on to other users, but maybe whatever happened in tbird to produce this "refinement" may have some other side effects.
If it stays as-is at least an update to the caps info page will be needed.
Thanks again bz

Comment 11

[Boris Zbarsky [:bzbarsky]]

So just to make sure we're on the same page...  You have "javascript.allow.mailnews" set to true in both builds?  And the 119 thing is only needed in the newer build?  Does the 119 thing work in the older build?  I would assume no...

Comment 12

[Joe Sabash [:JoeS1]]

Your assumption would be correct:
In tbird builds 20070618 and prior
including the port does not work,the domain name without the port does work.
20070619 and after:
you must include the port, otherwise caps ignores the directive.

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, I know what happened here.  The new code clones the mailnews URIs, which cannot be made immutable.

The point is that cloning them actually sets up the inner URI correctly(!).  The problem without that is that SetPort() currently doesn't correctly update the state of an nsStandardURL, so that calling GetHostPort() after calling SetPort() just gets the host, not the port.  The clone is reparsed from a string, so the problem goes away.

So given the mailnews code the port needs to be there in the security prefs.  I've filed bug 388281 on the SetPort() issue.