Open Bug 803999 Opened 13 years ago Updated 9 months 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

Hoping not to add noise, even though the following is almost only tangential:

  1. A (most likely incomplete) observation: The not-loading-of-symlinks is NOT consistent. When developing a Firefox extension and loading it (from the local filesystem) at Firefox special URL about:debugging#/runtime/this-firefox, if the directories/files referred to from manifest.json are symlinks, some DO GET LOADED - that is, at least the extension's toolbar icon does get loaded even through a symlinked directory. But, the scripts (and options HTML, and possible more) do NOT get loaded via symlinks. This inconsistency/difference may be intentional, or it's a Firefox defect.

  2. On Linux/Mac OS you could workaround with hard links, but, of course, only if

  • it's all on the same filesystem (partition), and
  • not feasible if you have too many files, or if they are auto-generated and the come and go, and
  • the worst: not compatible with some editors that don't just updates files on save, but they re-create the files. Configurable in some editors.

  1. On Linux you could mount over existing filesystem(s) (UnionFS? or some FUSE ones?), effectively creating a new filesystem tree from multiple filesystems, but for most of us life is too short...

  2. A limited workaround if the only/main reason for symlinks is not to have (some) local modifications reflected/noticed/collected by (local) git (so as to avoid their accidental commits to GIT). For that I use git update-index --skip-worktree path-to-where-ignore-local-modifications. (See also script manifest-firefox-override.sh for https://github.com/floccusaddon/floccus/pull/1848, it links to to more explanation).

You need to log in before you can comment on or make changes to this bug.