Closed Bug 167806 Opened 22 years ago Closed 22 years ago

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

Categories

(Core :: Networking: File, defect)

Product:
Core
Component:
Networking: File
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 84128

People

(Reporter: whiplash, Assigned: dougt)

References

(
URL
)

Details

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
Closed: 22 years ago
Resolution: --- → DUPLICATE
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
Of course I searched.  Apparently, however, on insufficient criteria :)
Depends on: 169106
You need to log in before you can comment on or make changes to this bug.