CAPS disregards site policy in recent trunk




Security: CAPS
11 years ago
11 years ago


(Reporter: JoeS1, Assigned: dveditz)



Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060804 Firefox/ (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://");
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

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

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.
Keywords: regression

Comment 2

11 years ago
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
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:

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).
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....
Although, even if I set "javascript.allow.mailnews" to true, things don't work.  Investigating.
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...
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

11 years ago
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://
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
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

11 years ago
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.
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.
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.