Closed Bug 463353 Opened 16 years ago Closed 16 years ago

security error: local file can't open other local files if they are in a different folder tree (only effects xml)

Categories

(Firefox :: Security, defect)

3.0 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 397894

People

(Reporter: alavaliant, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3

It seems starting with firefox 3  the security settings now seem block local xml files from loading a xml stylesheet if it's in lower level in the folder tree than the xml file. 

I have an xml document which specifies in it 
<?xml-stylesheet 

href="file:///path/to/stylesheet.xml" type="text/xsl"?>

if that stylesheet path is the same location as the xml file or a subdir under that location the stylesheet loads ok.  If I put the style sheet lower down in the tree (say specify ../stylesheet.xms or put on a different file path altogether to the xml file I get a security error in the console and the style sheet isn't loaded.    Having the stylesheet in a lower point in the file tree works in IE7 or in FF2  so this seems to be a regression in FF3.

I've also tried overriding the security settings using 
in user.js things like

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", " file:///path1 file:///path2");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

etc, with that I can allow the xml file if stored on a webserver (http://) to access the file:// location for the xml stylesheet.   I doesn't seem to work for allowing a file:// location xml file to access another file:// location for a stylesheet.
 


Reproducible: Always

Steps to Reproduce:
1.   get an xml document that links to an external stylesheet
2.   store that xml document locally (say c:\folder1\test.xml)
3.   put the style sheet for that xml document somewhere else such as c:\folder2\stylesheet.xml
4.   load up the xml document and you'll see that the xml stylesheet has not been applied, an security error should be in the error console.
Actual Results:  
xml stylesheet isn't applied to xml document and error console reports

Security Error: Content at file:///proj/avatar/dev/vegPltExo/hermitBudB/tmp/rib/jlemmon_lifToolRender/forSupport.stats.xml may not load data from file:///vol/apps/prman-14.0_64/etc/html/rmStatsHtml_1.1.xml.

Expected Results:  
xms style sheet is applied to the document and no errors in the console.
I first ran into this issue in a Linux environment as you'll see from the paths in the copy and paste of the error console output.    I putting the files on a windows box and updating the paths (since I guessed most people would be using windows.) the error was present there as well so it appears to be cross platform.   I didn't bother testing osx.
Version: unspecified → 3.0 Branch
Here is a test case of sorts.
Save the below text between the --- as an xml file

-----------------

<?xml version='1.0' encoding='ISO-8859-1'?>
<?xml-stylesheet type="text/xsl" href="file:///tmp/stylesheet.xml"?>
<rm:statsDoc xmlns:rm="http://example.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="eample.com.xsd">
    <stats name="frame1" description="test" kind="frame">
	

	
    </stats>
</rm:statsDoc>


-------------------


try loading the the xml file in ff3 and you'll get a blank screen (provided you saved the xms file to somewhere other that /tmp which is where my example looks for it's stylesheet),  you'll see a security error in the error console.

then try loading the xml file in ff2 and you'll instead see an error about not being able to find the stylesheet.   (no security error, it just can't find the stylesheet because we don't have one in this test.)




I can understand if this is some security lockdown that was intentionally done but no ability to override it with the capability.policy settings  is making it rather hard to deal with.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.