431133 - security.fileuri.strict_origin_policy preference is getting in the way of allowing privileges

Status: RESOLVED INVALID

(Core :: Security: CAPS, defect)

Description

[Martijn Wargers (dead)]

I have this in my user.js file:
user_pref("capability.principal.p0.granted", "UniversalXPConnect UniversalBrowserWrite UniversalBrowserRead");
user_pref("capability.principal.p0.id", "file:///");
user_pref("capability.principal.p0.subjectName", "");
, which means I'm allowing privileges for all local files (right?).

But between 2008-03-20 and 2008-03-21, something changed, which caused the privileges dialog to popup still.
Setting the security.fileuri.strict_origin_policy preference to false fixes the issue for me.
But a preference like that shouldn't influence that, no?
It took me quite a while to figure this all out, but the annyoance of repeatedly getting these security dialogs was driving me crazy :(

As a sidenote, I had >4000 pref lines in my prefs.js related to allowing enhanced privileges to local files, a lot of them were actually duplicates. It caused a severe slowdown on start-up.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This looks like a duplicate of bug 427051, no?  With the new pref, you have to list the files involved explicitly...

Comment 2

[Martijn Wargers (dead)]

Which new pref? You mean the security.fileuri.strict_origin_policy pref?
From http://kb.mozillazine.org/Security.fileuri.strict_origin_policy
I'm only seeing some mentioning about accessing other files, not about restricting enhanced privileges.

For my testing, I make new uniques files (with unique filenames) that need to have enhanced privileges, so listing files individually doesn't work for me.
I would like to give certain directories enhanced privileges, ideally.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Er, I meant with the new security policy.  But yes, toggling the strict_origin_policy pref will change the behavior to what it used to be, including privileges.

> I'm only seeing some mentioning about accessing other files, not about
> restricting enhanced privileges.

The pref affects the definition of "same origin".  Privileges are granted per-origin.

> For my testing, I make new uniques files (with unique filenames) that need to
> have enhanced privileges

Sounds like either you need to toggle the pref to get the old behavior, or you need to dynamically generate profiles with the right prefs, or we need a whole new infrastructure for granting privileges permanently to a whole bunch of origins at once...  The directory thing might work as a special-case for file://, but it wouldn't be a simple patch.

Comment 4

[Martijn Wargers (dead)]

Ok, thanks for the info, Boris.
So the security.fileuri.strict_origin_policy preference is getting in the way of allowing privileges on purpose.
That means this bug is invalid.

I don't need a new infrastructure for granting privileges. Toggling the pref to false will do for me just fine. But because of my lack of knowledge of what the pref is doing, led me to believe the pref was doing something weird.

The documentation on this subject seems insufficient, though, especially because bug 427051 is so annoying (to me at least).

Comment 5

[Boris Zbarsky [:bzbarsky]]

Bug 427051 we definitely need to fix.  And yeah, the documentation might need improvement... Can you describe what would be useful?

Comment 6

[Martijn Wargers (dead)]

Well, I can describe what I sort of expected: 
I would expect this one to grant enhanced privs to every file on my computer:
user_pref("capability.principal.p0.id", "file:///");
I would expect this one grant enhanced privs to everything under this directory:
user_pref("capability.principal.p0.id", "file:///C:/files/");

What I didn't know was that the security.fileuri.strict_origin_policy pref disallowed that kind of thing to work unless I set that pref to false. I just found about that pref by accident.