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:126.96.36.199) 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
CC'ing firstname.lastname@example.org 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?
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....
Oh well... thanks for looking into this :-).
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.