Open Bug 803999 Opened 12 years ago Updated 2 years ago

Opening symlinks in the file:/// scheme breaks relative links

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: nik, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0 Iceweasel/16.0.1
Build ID: 20121011223555

Steps to reproduce:

Create a directory structure as follows:

/tmp/foo
|- index.html -> /tmp/bar/index.html
|- test.gif
/tmp/bar
|- index.html

Put the folowing or similar in /tmp/bar/index.html:

<html><body><img src="test.gif" /></body></html>

Open file:///tmp/foo/index.html in Firefox.


Actual results:

Firefox resoves the symlink in /tmp/foo itself, redirects to file:///tmp/bar/index.html and breaks the relative link to test.gif.


Expected results:

Firefox should jsut go and open the file it was told to, leaving the rest to the operating system. This is how it behaves for remote resources, e.g. on a HTTP webserver, as well.
Component: Untriaged → File Handling
See Also: → http://bugs.debian.org/691099
I posted in this to threads the same issue beacuse I'm a developing something with bdd on top of my own javascript framework.

https://support.mozilla.org/en-US/questions/929923
http://support.mozilla.org/en-US/questions/951431

I found this was added intentionally by mozilla team to prevent security risk.
And it was made thru the channel of the file protocol.

I cloned the mozilla-central on github and provided a solution: Add boolean preference netowork.file.allowSymlinks in about:config

I want to make pull request for this change to be accepted. I think I have to talk to the module owner, but I have never collaborated before. Can someone please help with the process?

Thanks
(In reply to txema.gonz from comment #1)
> I posted in this to threads the same issue beacuse I'm a developing
> something with bdd on top of my own javascript framework.
> 
> https://support.mozilla.org/en-US/questions/929923
> http://support.mozilla.org/en-US/questions/951431
> 
> I found this was added intentionally by mozilla team to prevent security
> risk.
> And it was made thru the channel of the file protocol.
> 
> I cloned the mozilla-central on github and provided a solution: Add boolean
> preference netowork.file.allowSymlinks in about:config
> 
> I want to make pull request for this change to be accepted. I think I have
> to talk to the module owner, but I have never collaborated before. Can
> someone please help with the process?
> 
> Thanks

The modified code is at:

https://github.com/txemagon/mozilla-central
The standard process for getting code landed is to post a patch file on a bugzilla bug, and get it reviewed by a module-owner / peer.

So in this case, you should generate a patch file from your git commit, and post it on this bug (or another more targeted "add pref to do $X" bug), and request review from jduell or someone on the network team.  (You should definitely involve someone who was part of the original change that you're trying to work around, too, to be sure that you're not missing something from that original bug.)
(For reference, txema's proposed patch is:
 https://github.com/txemagon/mozilla-central/commit/52119cb9dc1be2f8c326bbfc2c5bceef872c9683
)

Looks like bug 670514 is where we added the current behavior.  I don't know the full story there, but from skimming the first comment, I'm not sure your use case is strong enough to offset the risk involved with giving users a pref that would reopen them to that attack.

It's not my call; I just want to make sure you're aware that there's definitely a risk tradeoff here.
Component: File Handling → General
Depends on: CVE-2012-1945
Product: Firefox → Core
Version: 16 Branch → Trunk
This is very frustrating. A lot of file organization schemes rely on symlinks; e.g., I am storing a lot of HTML documents in a git annex repository, where each document is moved into its own hashed subdirectory. Because Firefox insists on dereferencing symlinks before opening a file, I cannot use these documents anymore. Since it’s typical for locally saved documents to use relative symlinks, derefencing links before opening them effectively removes symlink support completely.

On the Debian bugtracker someone posted a work-around based on LD_PRELOAD, though I couldn’t yet ascertain whether it still works. Just in case anyone is looking for a work-around.
Sorry, I forgot adding the URL to the work-around.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691099
I would be open to a proposed fix for this that does not reintroduce the security problems fixed in bug 670514 (which is now public, so people can evaluate what those problems were).
This limits the usefulness of Firefox as a local file browser. Working on a markdown file, want to view it in both text and markdown modes, editing as somefile.txt with symbolic link somefile.md -> somefile.txt. Firefox dereferences link and will not trigger markdown formatting extension. Resolved problem by using Chromium web browser. Working in *nix environment, Ubuntu 16.04, Firefox 57.0.1 64-bit. An option to allow users to disable rewriting urls for FILE: access would resolve this issue.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.