424594 - have talos comply with new file:// security restrictions.

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[alice nodelman [:alice] [:anode]]

We have a stop gap solution of setting:

security.fileuri.strict_origin_policy : false

This caused bug 424571.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  Did the talos boxes use to not prompt because the profile already has privileges granted?

Comment 2

[alice nodelman [:alice] [:anode]]

Yes - the profile already has the privileges granted.  

Is there something else that I need to do to be in line with the new security
requirements?  I've been fiddling around with moving the quit.js file to be in
the directory that it is being called from, but that doesn't seem to be enough
to get around the security dialog.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This should be working...  What are the file:// paths involved and what is the pref in the profile?

Comment 4

[alice nodelman [:alice] [:anode]]

In the profile I have the following:

user_pref("capability.principal.codebase.p0.granted", "UniversalPreferencesWrite UniversalXPConnect UniversalPreferencesRead");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");

The first thing that I hit is with file://c:/mozilla/testing/performance/talos/getInfo.html 

It calls quit.js and raises the security dialog.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I suspect you want to change the "file://" thing to the actual file URI to your file.  And we might want a separate bug on CAPS to change GetPrincipalDomainOrigin() to special-case file:// URIs...  Otherwise the message in the dialog is not useful (it's just saying that something at "file://" wants privileges, right?).

Comment 6

[alice nodelman [:alice] [:anode]]

I'll give your suggestion a try, but if that ends up being the solution then I'm going to have some trouble implementing it - since the location of the various test files that I run vary depending upon platform and allocation.

And yes, the error message dialog is not particularly informative.

Comment 7

[alice nodelman [:alice] [:anode]]

From my tests it looks like this can all be avoided by having the few tests that currently operate through file:// go through http://localhost (since we always have a local web server on test machines this works out of the box).

Standalone talos code would have to have the security.fileuri.strict_origin_policy set to false, though - since it is set up currently to have everything run through file:// load.

Would this be an acceptable solution?

Comment 8

[Boris Zbarsky [:bzbarsky]]

I think just flipping the strict origin pref for talos (either standalone, or in general) is just fine.  dveditz, any thoughts?

Comment 9

[Boris Zbarsky [:bzbarsky]]

I filed bug 425880 on the CAPS changes I think we need.

Comment 10

[alice nodelman [:alice] [:anode]]

Attachment: add security.fileuri.strict_origin_policy setting to talos configs

From my reading of the bug it is okay to go ahead with simply adding the security setting security.fileuri.strict_origin_policy/false to the talos configs (production, stage and try talos).

Comment 11

[alice nodelman [:alice] [:anode]]

Checked in attachement #1.  This won't require any buildbot reconfigs as we already have this preference set for active talos machines as a means of sidestepping the problem, this just gets the contents of cvs lined up with what we are actually running.

Comment 12

[alice nodelman [:alice] [:anode]]

Attachment: add security.fileuri.stric_origina_policy setting to base talos config

Just noticed that I missed setting this for the standard config file included in the mozilla/testing/performance/talos directory.

Comment 13

[alice nodelman [:alice] [:anode]]

Checking in sample.config;
/cvsroot/mozilla/testing/performance/talos/sample.config,v  <--  sample.config
new revision: 1.14; previous revision: 1.13
done

I've also updated standalone talos to use the setting:
http://wiki.mozilla.org/StandaloneTalos

I think that that is all the currently used config files.  That fixes the bug - we can reopen if we determine that we would prefer not to have the setting and would like to find another solution.