425880 - GetPrincipalDomainOrigin might need tweaking with strict file:// origins

Status: NEW

(Core :: Security: CAPS, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Right now GetPrincipalDomainOrigin gets "file://" as the domain origin for all file:// URI principals.  I think using either the exact filename or a file URI to the parent directory would make more sense when the strict file:// policy is enabled.  Otherwise we get situations where the dialog says "file://" is requesting permissions, but it's actually a particular file, and worse yet saving the decision to prefs won't work right...

I'm not sure whether there are also security implications here, so I doubt this absolutely needs to block.  But if we don't fix it by ship, we should really do it in point release.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not sure whether GetOrigin() needs a tweak too.

Comment 2

[João Pedro Afonso]

Are you proposing that GetPrincipalDomainOrigin gave different domains origin for file:// URI principals, or that URIs inside that domain be treated differently from other domains?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I'm proposing that GetPrincipalDomainOrigin return the entire URI or the URI to the parent directory instead of scheme+host+port for file:// URIs.

Comment 4

[João Pedro Afonso]

You have my sympathy for the returning of the parent directory if I understand the logic. Sometimes, we implement whole sites in the disk, either ours or ripped from the net. Wouldn't it break consistency if the domain for those sites in the net became multiplied in one per file while in the harddisk?

At the same time, I like the possibility of grant/denies in a per-file base... which I suppose plays in favor of the return of the complete URI. If it wouldn't add too much confusion, the best would be to concede the user some fine grain of control here: they would decide to allow the domain (in this case, the parent directory) or the individual file in it. Doesn't capability.principal.codebase's prefs.js syntax allows this?

By the way, shouldn't we have some kind of manager for listing the saved authorizations conceded? I looked in the about:config and in the security pane of options and found none. Sorry, if this questions is off-topic.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Wouldn't it break consistency if the domain for those
> sites in the net became multiplied in one per file while in the harddisk?

It already is in Firefox 3, in all parts of the security system _except_ this one function.  The only thing affected by this function is what happens when files prompt for expanded privileges.

> shouldn't we have some kind of manager

As you said, off-topic.

Comment 6

[Avi Halachmi (:avih)]

FWIW, I think the stricter suggested solution (full URI) is more adequate for file:// scripts than a containing folder URI.

"local HTML/JS applications" which need restricted privileges can put all their restricted functionality into a single file, and then the user only has to approve this file, which is dedicated for said application, thus essentially approving a specific application.

If the containing folder approach is used instead, it could grant privs for all scripts on the desktop when the user approved only one. Saving many files a single location (be it the desktop, the 'downloads' folder, etc) is not uncommon among the less tech-oriented users IMO.

At worst, the full URI approach makes life slightly less comfortable for developers by requiring them to put all restricted functionality into a single file, but it better takes care of the users IMO.