Last Comment Bug 307382 - [FIX]Remove support for "security.checkloaduri" = false
: [FIX]Remove support for "security.checkloaduri" = false
Status: RESOLVED FIXED
: fixed1.8
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: Trunk
: All All
: P2 normal with 1 vote (vote)
: mozilla1.8beta5
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
http://weblog.wlkr.net/archives/2005/...
Depends on: 1042975
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-07 10:11 PDT by Benjamin Smedberg [:bsmedberg]
Modified: 2014-07-23 14:42 PDT (History)
8 users (show)
asa: blocking1.8b5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Like so (5.21 KB, patch)
2005-09-08 21:31 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review
Er, the real thing (4.23 KB, patch)
2005-09-08 21:32 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review
Same as diff -w (3.27 KB, patch)
2005-09-08 21:33 PDT, Boris Zbarsky [:bz] (still a bit busy)
caillon: review+
dveditz: superreview+
asa: approval1.8b5+
Details | Diff | Splinter Review

Description Benjamin Smedberg [:bsmedberg] 2005-09-07 10:11:56 PDT
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 [:bz] (still a bit busy) 2005-09-07 10:31:28 PDT
We should probably updated whatever documentation we have accordingly, too.  And
update the Mozillazine knowledge base.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2005-09-08 21:31:55 PDT
Created attachment 195360 [details] [diff] [review]
Like so
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2005-09-08 21:32:30 PDT
Created attachment 195361 [details] [diff] [review]
Er, the real thing
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2005-09-08 21:33:15 PDT
Created attachment 195362 [details] [diff] [review]
Same as diff -w
Comment 5 Daniel Veditz [:dveditz] 2005-09-09 07:32:24 PDT
Comment on attachment 195362 [details] [diff] [review]
Same as diff -w

yup, sr=dveditz
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2005-09-09 12:40:59 PDT
Fixed on trunk.  So do we want this on the 1.8 branch?  I'm tempted to say "yes"...
Comment 7 Daniel Veditz [:dveditz] 2005-09-09 19:05:13 PDT
(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 [:bz] (still a bit busy) 2005-09-09 21:05:41 PDT
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 [:bz] (still a bit busy) 2005-09-12 18:45:38 PDT
Fixed on 1.8 branch.
Comment 10 James Slaughter 2005-09-13 06:12:22 PDT
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) 2005-09-13 06:24:17 PDT
there is no UI (other than about:config). you configure the sites that serve the
HTML files with the links.
Comment 12 James Slaughter 2005-09-13 06:38:39 PDT
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) 2005-09-13 06:58:04 PDT
> 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 [:bz] (still a bit busy) 2005-09-13 08:24:11 PDT
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) 2005-09-14 12:33:38 PDT
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 [:bz] (still a bit busy) 2005-09-14 12:46:41 PDT
Feel free to file a followup bug on that.  Patches accepted...
Comment 17 David Hupperich 2005-11-26 02:55:56 PST
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 [:bz] (still a bit busy) 2005-11-26 09:00:08 PST
No idea; using those exact preferences works for me.
Comment 19 beanladen 2006-02-14 11:50:58 PST
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 [:bz] (still a bit busy) 2006-02-14 12:06:49 PST
> 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 2006-02-14 12:24:18 PST
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.

Note You need to log in before you can comment on or make changes to this bug.