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
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: 670514
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.
You need to log in before you can comment on or make changes to this bug.