93787 - allow security.checkloadURI exceptions via paired URL-filesystem expressions

Status: NEW

(Core :: Security, enhancement)

Description

[benc]

Mitchell had commented that domain based exceptions to this feature might be a
good idea, and I could not find an RFE on that feature, so I'm creating it here...

I propose the following:

A preference that accepts some kind of paired URL prefix. The first part
describes URLs allowed to make an exception to get file: URL access to the
second expression.

For example:
http://www.packetgram/push/* + file:/usr/local/push/*

(Someone can probably come up with saner syntax, but you get the idea).

The pref could be in the UI, or via the next-gen Mission Control, or hacking
prefs.js, this should be discussed.

Interestingly, this would be much more secure if you used https: in the first
pair, because it would prevent spoofing of references to the local filesystem.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Ben and I discussed this. I may do it if there's a huge demand. In the meantime,
we have the binary "security.checkloaduri" pref.

Comment 2

[benc]

This would probably be the most direct way of giving people what they want in
bug 84128. Right now, if you turn off checkloaduri, it is all-or-nothing.

Comment 3

[charles allen]

Finally I found it!  Yes, you need something like this to allow mozilla to be
used as a replacement for IE in intranets.  Perhaps you need three columns:

ALLOW: 
remote protocol     domain                 local protocol
http               *.math.clemson.edu      file://///*
https              *.clemson.edu           file://///*

DISALLOW:
remote protocol    domain                    local protocol:
https              *.students.clemson.edu    file:*

and I think this should default to:
ALLOW
remote protocol    domain                                    local protocol:
https              <local domain determined by IP address>   file:///*

Comment 4

[Ian Neal]

How would this work for file:// links within emails?

Comment 5

[Ian Neal]

If so then bug 135830 should probably be marked as a dupe

Comment 6

[benc]

You could have the sending domain of mail be assumed to be the domain of the
base, but this is too easy to forge.

People should not be sending file URL's in documents they create, even though
MailNews does this all the time in "Send Page" (bug 136782).

Comment 7

[Ian Neal]

Unless of course it's internal email within a company where everyone has access
to a shared network drive. At which point file:// links make perfect sense as it
means people aren't clogging up the email system with lots of attachments.

Comment 8

[beanladen]

We in our institute are DAILY sending file URL's in mail because we don't
want to have our people have to save or to download papers to which they
have local access anyway. So the typical thing we do is to send a mail 
with a file URL where to find the document. I think this is a perfectly 
legitimate and space and network traffic saving habit.

Comment 9

[Samir Gehani]

adt: nsbeta1-

Comment 10

[Serge Gautherie (:sgautherie)]

(coming here from bug 233108 comment 21)

A configured site+directory pair would be perfect to solve my case in bug 264968
comment 11 too:
something like 'http://www.battle-arenas.net/* <->
file:///W:/Progs/@Battle-Arenas/ba_pack/*'.

Comment 11

[Michael]

This is my situation.  I have been fighting this bug/issue since Netscape 4
days, and I have seen many bugs and comments about it.

This problem is still there in FireFox 1.0.  It is reproducible at will.  If the
CheckLoadURI problem can't be fixed, can we at least have a totally insane and
unsecure option that will allow us to link to file://f:/some.file bypassing ALL
security?

Please!

I thought the CheckLoadURI setting was supposed to allow this, but it doesn't. 
It never did, as far as I can tell.

The only thing that works right now is to load IE 5.5 and make it my default
browser, or force my users to right-click and open in a new window which
launches IE as well.  Then I can email a link to a file on my server and have it
work.

Thank you.

(In reply to comment #8)
> We in our institute are DAILY sending file URL's in mail because we don't
> want to have our people have to save or to download papers to which they
> have local access anyway. So the typical thing we do is to send a mail 
> with a file URL where to find the document. I think this is a perfectly 
> legitimate and space and network traffic saving habit.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)
> In the meantime,
> we have the binary "security.checkloaduri" pref.

This works,
and bug 233108 improved this recently :-)
Usage examples: see bug 84128 comment 194 and 199 !

(In reply to comment #10)
> A configured site+directory pair would be perfect to solve my case in bug 264968
> comment 11 too:
> something like 'http://www.battle-arenas.net/* <->
> file:///W:/Progs/@Battle-Arenas/ba_pack/*'.

What we still miss is the "file path" part: this bug !

Comment 13

[Daniel B.]

See bug 84128 comment 264
(https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c264).

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to comment #13)
> See bug 84128 comment 264

For those who want to read that comment (or not):
it is about "Suggestion: Track security level of operations requesting opening
URL, modeling after the Java privileged block API.".

Comment 15

[Jimmy Sieben]

Is this the same as Bug 233108 ?

Comment 16

[Ian Neal]

(In reply to comment #15)
> Is this the same as Bug 233108 ?

see comment #12

Comment 17

[Michael Augustin]

What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it works untill Firefox 1.0.x . In version 1.5 this old security violation message popup in the java-console-view, but the file isn't loaded. In about:config my parameter is still set to "security.checkloaduri=false".

Comment 18

[Serge Gautherie (:sgautherie)]

(In reply to comment #17)
> What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it
> works untill Firefox 1.0.x . In version 1.5 this old security violation message

I guess you should try the |user_pref("capability.policy.xyz", "xxyyzz");| preferences after "Gecko/Trunk" v1.8a5.

Probably, this bug should be morphed to take this into account !!?

Comment 19

[Jim Tuttle]

It's been almost 7 years since this enhancement request has been opened and 2.5 years since the last comment.  I've been tracking the related bug #84128 (which is even older than this one), and just came across this item.
 
A solution to this enhancement request would be better than just the user-visible warning bug #84128 is asking for, so... any updates?  And, no, asking users to install "IE Tab" or edit their prefs.js, etc, is not acceptable.

We have GUIs (of a sort) to allow users to allow blocked pop-ups from certain sites.  Why can't we have the same type of notification & override for "blocked" file:// URLs?  I don't see why blocked file:// URLs should be treated any differently than pop-ups from the USER'S point-of-view.  They are both things that are annoying and/or dangerous, but there are times & sites for which you NEED those things (esp. if it's something that you explicitly clicked on!).

Thanks,
   Jim