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



Release Engineering
10 years ago
4 years ago


(Reporter: alice, Assigned: alice)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



10 years ago
We have a stop gap solution of setting:

security.fileuri.strict_origin_policy : false

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

Comment 2

10 years ago
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.
This should be working...  What are the file:// paths involved and what is the pref in the profile?

Comment 4

10 years ago
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.
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

10 years ago
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

10 years ago
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?

I think just flipping the strict origin pref for talos (either standalone, or in general) is just fine.  dveditz, any thoughts?
I filed bug 425880 on the CAPS changes I think we need.


10 years ago
Priority: -- → P2

Comment 10

10 years ago
Created attachment 315655 [details] [diff] [review]
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).
Attachment #315655 - Flags: review?(rcampbell)
Attachment #315655 - Flags: review?(rcampbell) → review+

Comment 11

10 years ago
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

10 years ago
Created attachment 316315 [details] [diff] [review]
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.
Attachment #316315 - Flags: review?(rcampbell)
Attachment #316315 - Flags: review?(rcampbell) → review+

Comment 13

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

I've also updated standalone talos to use the setting:

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.
Last Resolved: 10 years ago
Resolution: --- → FIXED


9 years ago
Component: Release Engineering: Talos → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.