307382 - [FIX]Remove support for "security.checkloaduri" = false

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect, P2)

Description

[Benjamin Smedberg]

People keep doing this, and it's frankly a poor decision every way round. We now
have the ability to disable checkloaduri per-site, so let's get rid of the
terrible global pref.

Comment 1

[Boris Zbarsky [:bzbarsky]]

We should probably updated whatever documentation we have accordingly, too.  And
update the Mozillazine knowledge base.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Er, the real thing

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as diff -w

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 195362 [details] [diff] [review]
Same as diff -w

yup, sr=dveditz

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.  So do we want this on the 1.8 branch?  I'm tempted to say "yes"...

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to comment #6)
> Fixed on trunk.  So do we want this on the 1.8 branch?  I'm tempted to say
"yes"...

me too. a=me, but the 1.8 branch needs more than one driver at this point.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 195362 [details] [diff] [review]
Same as diff -w

Well, let's go for approval and I'll see about writing up some docs for this.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8 branch.

Comment 10

[James Slaughter]

Where is the UI to whitelist sites to access file:// URIs? I will need to be
able to configure this in order to use my company's intranet. Do I whitelist the
sites serving the HTML pages containing the file links, or the systems from
which file URIs can be loaded?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

there is no UI (other than about:config). you configure the sites that serve the
HTML files with the links.

Comment 12

[James Slaughter]

Thanks. I've just found http://kb.mozillazine.org/Links_to_local_pages_don%27t_work.

<facetious>
Do I understand that "capability.policy.default.checkloaduri" is an equivalent
preference, and that this change is more about annoying corporate users than
increasing security?
</facetious>

Really, I have no problem with removing support for cruft, and I guess this has
forced me to learn about the policy system. Tell me, can that mechanism control
when referer headers are sent?

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

> this change is more about annoying corporate users than increasing security?

...

Obviously this change is not about annoying people. It is to make people only
enable it for specific sites that require it, it is too much of a security
problem to allow it to be enabled for every site.

Comment 14

[Boris Zbarsky [:bzbarsky]]

This change was made because people were advising everyone in sight to set the
old pref, which makes users vulnerable.  By forcing people to use the new setup,
which has existed for a while now, we make it so they have to enable access on a
per-site basis (unless they mess with the "default" policy, of course, but we
plan to not document that).

Comment 15

[Nitin (vfwlkr)]

If its not annoying corporate users, its not making their lives any easier.

bug 231529 added a pref that allowed enabling unprompted NTLM on intranet links
using the pref: 
network.automatic-ntlm-auth.trusted-uris

Now this requires another list at:
capability.policy.localfilelinks.sites

How about adding a global list of intranet sites at something like:
network.intranet.uris
which would be included at both places - to allow NTLM authentication, allow use
of file:// links (which is primarily for windows based servers, not local hdd).

PS: Wasnt aware of the new prefs when I made that blog post.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Feel free to file a followup bug on that.  Patches accepted...

Comment 17

[David Hupperich]

i use 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

i edited the user.js:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://intranetserver");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

i used the correct path, eg: file:///D:/images/blank.gif

but the browser does not show the image. what did i wrong?

Comment 18

[Boris Zbarsky [:bzbarsky]]

No idea; using those exact preferences works for me.

Comment 19

[beanladen]

And how can the new scheme be used to link from mails to local content ? 
That worked with security.checkloaduri=false, but I cannot see how to enable 
it with the new scheme for all mails in all my mailboxes.
Should it be mailbox://....  (I tried that once, but it didn't work) ?
In our institute, this feature is heavily used to prevent sending huge papers
locally to everyone (where it is saved then multiple times), instead providing 
a link from the mail to the local home directory of the respective user, which
saves a lot of disk space and network bandwidth.
If the new scheme cannot provide the access, I request the old switch be
reintroduced for local content link from mails only until it is integrated
in the current scheme (which is, btw, an *excellent* solution!).

Comment 20

[Boris Zbarsky [:bzbarsky]]

> And how can the new scheme be used to link from mails to local content ? 

See bug 84128 comment 214 and bug 84128 comment 211.

If nothing else, I suspect that "mailbox:" will work (unlike "mailbox://").  Compare http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#291

Comment 21

[beanladen]

Bingo! It works with Seamonkey 1.0 and 'mailbox://' (but not mailbox: or 
mailnews://) . Thanks for that hint ! It should be documented somewhere, 
maybe at
<http://kb.mozillazine.org/Links_to_local_pages_don%27t_work>
where most of the related bugs point to.