Same-origin policy for local files doesn't work with symlinked directories

NEW
Assigned to

Status

()

Core
Security: CAPS
9 years ago
5 years ago

People

(Reporter: William J. Edney, Assigned: dveditz)

Tracking

(Blocks: 1 bug)

unspecified
x86
All
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

A new same origin policy for local files was enacted as detailed here: https://bugzilla.mozilla.org/show_bug.cgi?id=230606. This new policy is supposed to allow access to files at the same level as the 'file://' based page or subdirectories under it.

However, if a subdirectory is 'symlinked' in (as in can be in *nix file systems, like the Mac and Linux), files in that subdirectory cannot be accessed.


Reproducible: Always

Steps to Reproduce:
1. Symlink a directory at the same level as the page you're loading from the file:// system.
2. Try to access files in that directory using XMLHttpRequest() with a 'file://' URL
3.
Actual Results:  
Security errors

Expected Results:  
Normal file access
(Reporter)

Comment 1

9 years ago
CC'ing bzbarsky@mit.edu at his request.

Cheers,

- Bill
So something like:

  cd
  ln -s ../foo bar

then try to access ~/bar/index.xml from ~/test.html ?  If not, then exactly what are the source and target of the symlink in relation to the HTML file the XHR is running in?
(Reporter)

Comment 3

9 years ago
Boris -

Yes, that's it exactly.

Thanks!

Cheers,

- Bill
Bill, no need to sign every comment; your name is attached to it anyway.  ;)

It looks like the issue is that nsIFile::Normalize() follows symlinks.  I thought we had a bug on this, but I can't find it right now.  The Normaliz() call is necessary to fix bug 395343.

I'm not sure there's much we can do to fix this without introducing a huge amount of (security-bug-prone) complexity....
Assignee: nobody → dveditz
Component: General → Security: CAPS
Product: Firefox → Core
QA Contact: general → caps
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

9 years ago
Oh well... thanks for looking into this :-).

Updated

9 years ago
Flags: in-testsuite?

Updated

9 years ago
Blocks: 484290

Comment 6

5 years ago
Starting around FF 14, I've got a similar problem. But I don't get any kind of security notice, the page just doesn't load. And setting security.fileuri.strict_origin_policy to true doesn't help. I guess I should file a new bug for this.
You need to log in before you can comment on or make changes to this bug.