The default bug view has changed. See this FAQ.

UNC (Windows SMB) paths work only in Address Bar, not from links

VERIFIED DUPLICATE of bug 84128

Status

()

Core
Networking: File
VERIFIED DUPLICATE of bug 84128
15 years ago
15 years ago

People

(Reporter: Gordon Schumacher, Assigned: dougt)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

If I type an address of the form file://///foo/baz (five slashes) into the
address bar, I get a file listing of the network share.

However, if I include the same link on a Web page, clicking on it yields no
response.

Reproducible: Always

Steps to Reproduce:
1. Set up a Windows file share.  Assume machine name FOO and share name BAZ.
2. Type the following into the Address Bar: file://///FOO/BAZ
3. Click on the link in the following HTML:

<HTML>
<HEAD><TITLE>This Is Broken</TITLE></HEAD>
<BODY>
<A HREF="file://///FOO/BAZ">This Will Do Nothing In Mozilla</A><BR>
</BODY>
</HTML>

4. Now repeat both steps in IE (any version since 3.0, at least).
Actual Results:  
2. Typing into Mozilla's Address Bar works fine.
3. Clicking on the link in Mozilla does nothing.
4. The IE test works fine.

Expected Results:  
Steps 2 and 3 should have yielded identical results.
That is totally by design.  A website should not have any access to load things
from your hard drive.  By loading things, websites may be get access to their
contents which may lead to other bad security issues.  That said, we should put
up a dialog when this happens so that you know we're intentionally refusing to
load it.

*** This bug has been marked as a duplicate of 84128 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

15 years ago
But a website doesn't "gain access" to file:// links, since they don't go
through a server - only the browser!  The only way that a malicious webpage
could "gain access" is something like via Java or JavaScript - which would imply
that there's a security problem on that end.

Security issues aside for the moment, blindly not allowing local filesystem
links precludes the use of using Mozilla to browse some Intranet sites.  How
about a "security zone" type model - only allowing this sort of behaviour within
a certain domain?

Yes, yes, I know.  In order to do a proper Intranet site, the server should have
access to all the filesystems in question, and you shouldn't be using UNC paths
in the first place.  In my case, I don't get that kind of control over the site
as a whole (being for rather a large company) - the storage location for a
particular application is designated as being at a particular UNC resource.  My
choices are either to link to the UNC path off of the page, or to duplicate *the
entire directory tree* in order to have a copy on the webserver.  The latter
will lead to synchronization issues... so right now, the only answer is "Use IE"
- not very good.

I'll leave this marked as resolved, against my better judgement - but this
*does* preclude our attempts to ditch Mr. Bill's Browser.
There are many discussions about this bugs are very easy to find. (Have you
searched before you filed the bug ?)
There is a way to disable this check with a hidden pref but that can open
security problems.

verified dupe
Status: RESOLVED → VERIFIED
(Reporter)

Comment 4

15 years ago
Of course I searched.  Apparently, however, on insufficient criteria :)

Updated

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