The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.8beta5

Status

()

Core
Security: CAPS
P2
normal
RESOLVED FIXED
12 years ago
3 years ago

People

(Reporter: bsmedberg, Assigned: bz)

Tracking

(Depends on: 1 bug, {fixed1.8})

Trunk
mozilla1.8beta5
fixed1.8
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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.
We should probably updated whatever documentation we have accordingly, too.  And
update the Mozillazine knowledge base.
Created attachment 195360 [details] [diff] [review]
Like so
Created attachment 195361 [details] [diff] [review]
Er, the real thing
Attachment #195360 - Attachment is obsolete: true
Created attachment 195362 [details] [diff] [review]
Same as diff -w
Attachment #195362 - Flags: superreview?(dveditz)
Attachment #195362 - Flags: review?(caillon)
Priority: -- → P2
Summary: Remove support for "security.checkloaduri" = false → [FIX]Remove support for "security.checkloaduri" = false
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 195362 [details] [diff] [review]
Same as diff -w

yup, sr=dveditz
Attachment #195362 - Flags: superreview?(dveditz) → superreview+
Attachment #195362 - Flags: review?(caillon) → review+
Flags: blocking1.8b5?
Fixed on trunk.  So do we want this on the 1.8 branch?  I'm tempted to say "yes"...
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(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 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.
Attachment #195362 - Flags: approval1.8b5?

Updated

12 years ago
Attachment #195362 - Flags: approval1.8b5? → approval1.8b5+
Fixed on 1.8 branch.
Keywords: fixed1.8
Target Milestone: mozilla1.9alpha → mozilla1.8beta5

Comment 10

12 years ago
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?
there is no UI (other than about:config). you configure the sites that serve the
HTML files with the links.

Comment 12

12 years ago
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?
> 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.
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).

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+

Comment 15

12 years ago
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.
Feel free to file a followup bug on that.  Patches accepted...

Comment 17

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


No idea; using those exact preferences works for me.

Comment 19

11 years ago
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!).
> 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

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

Updated

3 years ago
Depends on: 1042975
You need to log in before you can comment on or make changes to this bug.