3.25 MB, application/octet-stream
3.25 MB, application/octet-stream
1.05 KB, patch
|Details | Diff | Splinter Review|
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz
1.71 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130730113002 Steps to reproduce: A local web application intended to be an off-line DVD, uses a local java applet. Up to version 22 it worked fine. The html is: <applet width="960" height="425" archive="jclic.jar" codebase="../jclic/" code="JClicApplet"> <param value="application/x-java-applet;version=1.4" name="type"> <param value="false" name="scriptable"> <param value="cap1-03J.jclic.zip" name="activityPack"> </applet> Trying to set codebase to a full path: "/...../jclic" and a full url: "file:///...../jclic" both still fail. The error happens both in Mac OS and Windows with Version 23 Actual results: The applet is not loaded. No error is shown. Java v is not invoked. Expected results: The applet loaded.
We need a testcase as an attachment and eventually a regression range using mozregression (see https://github.com/mozilla/mozregression).
Component: General → Plug-ins
Keywords: regression, regressionwindow-wanted, testcase-wanted
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 786840 [details] testcase. unzip and open ./html/index.html A Test case for the problem. Unzip and open ./html/index.html. The applet being loaded is in ./jclic/jclic.jar
Hi! Thanks Scoobidiver! About mozregression, I'm affraid I'm not being able to correctly install (and use). I'm not familiar with Mozilla development workflows. What I can tell is: It works correctly with release 22.0, Mac OS X and Windows It fails with release 23.0 (today August 7, 2013), both Mac OS X and Windows. Many thanks in advance. Dino
The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b48e06621dc9&tochange=dcbbfcdf7bb4 It's likely a regression from bug 888834 or bug 406541 .
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted, testcase-wanted → testcase
status-firefox23: --- → affected
tracking-firefox24: --- → ?
tracking-firefox25: --- → ?
tracking-firefox26: --- → ?
I believe that this is by design. Our same-origin policy for sites loaded from file: is that they may only access files in their directory and subdirectories. The codebase="../jclic/" indicates that this is trying to load Java from a parent directory. That is specifically what we were fixing. See https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs for background. If you flip the security.fileuri.strict_origin_policy pref to `false`, does that cause your Java to load? If so I expect that this is WONTFIX, but I'll let johns double-check me here.
Assignee: nobody → jschoenick
Hi Benjamin! Thanks for your work! First, I confirm that with security.fileuri.strict_origin_policy pref to `false` it works. We don't like the final user has to change the settings, so we can rearrange to find the java in a subdirectory. But we have prepared a second test case with this approach (java in a subdirectory and security.fileuri.strict_origin_policy = true). No success: It does not load the java. I have attached this second test case (case2.zip). Please confirm us if you reproduce the same behaviour. Many thanks again! Dino.
The regression range for the second testcase is still the same.
needinfo on John to help with comment #5 and understand if this is a valid bug ?
The case where codebases outside of the current directory are blocked is intentional -- however, the case where subdirectories do not work properly is not :(
Status: NEW → ASSIGNED
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox-esr17: --- → unaffected
Created attachment 787153 [details] [diff] [review] Actually use the optional parameter added explicitly for this purpose Sigh. Fail. Most of the code in 406541 was to split out NS_RelaxStrictFileOrigin to allow adding the aAllowDirectoryTarget parameter. If only the added security check actually called it... I added this to the tests for bug 406541, which haven't landed yet.
Attachment #787153 - Flags: review?(benjamin)
Created attachment 787154 [details] [diff] [review] Strict file origin policy - handle case where the target is the parent directory of the source Bonus edge case found while looking at this - the strict file origin logic might fail if the target of an operation is the parent directory of the given file, and aAllowDirectoryTarget = true. (with allowDirectoryTarget a file should be able to target its own directory)
Attachment #787154 - Flags: review?(bzbarsky)
Comment on attachment 787154 [details] [diff] [review] Strict file origin policy - handle case where the target is the parent directory of the source Can you assert that if NS_SUCCEEDED(rv) && allowed for the Equals() call (basically an else for the if you have there) then aAllowDirectoryTarget is true? r=me with that
Attachment #787154 - Flags: review?(bzbarsky) → review+
tracking-firefox24: ? → +
tracking-firefox25: ? → +
tracking-firefox26: ? → +
Created attachment 793159 [details] [diff] [review] Strict file origin policy - handle case where the target is the parent directory of the source. r=bz
Attachment #787154 - Attachment is obsolete: true
Comment on attachment 793159 [details] [diff] [review] Strict file origin policy - handle case where the target is the parent directory of the source. r=bz addressed review comments
Attachment #793159 - Flags: review+
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-firefox26: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
I don't know what the procedure for backports is on mozilla, but could this be backported to at least FF 24, since it is going to be an ESR release?
Comment on attachment 787153 [details] [diff] [review] Actually use the optional parameter added explicitly for this purpose [Approval Request Comment] Bug caused by (feature/regressing bug #): 406541 User impact if declined: Local (file://) pages that use Java don't work properly in some cases Testing completed (on m-c, etc.): On m-c Risk to taking this patch (and alternatives if risky): Very low, these changes only affect java applets on file URIs. String or IDL/UUID changes made by this patch: None
Comment on attachment 793159 [details] [diff] [review] Strict file origin policy - handle case where the target is the parent directory of the source. r=bz see comment 20
Tests for this will land with the 406541 tests
status-firefox22: --- → unaffected
status-firefox23: affected → wontfix
https://hg.mozilla.org/releases/mozilla-aurora/rev/f6a238e848d3 https://hg.mozilla.org/releases/mozilla-aurora/rev/1554a8d1eb6e https://hg.mozilla.org/releases/mozilla-beta/rev/19d4d4a86051 https://hg.mozilla.org/releases/mozilla-beta/rev/243498415456
status-firefox24: affected → fixed
status-firefox25: affected → fixed
Hi All! Just to confirm... With Nightly 26.0a1 (2013-08-23), my testcase works correctly. I will check with aurora and beta. Thanks!!
Verified as fixed on Firefox 24 beta 6 (20130826142034) - Windows 7 64bit, Ubuntu 13.04 32bit and Mac OSX 10.7.5. The applet in the first testcase doesn't load - as specified by design. The applet in the second testcase loads fine.
status-firefox24: fixed → verified
QA Contact: ioana.budnar
Also verified on Firefox 25: Mac OS X 10.8.4 - 20130912004004 Ubuntu 13.04 - 20130911004006 Windows 7 - 20130912004004
status-firefox25: fixed → verified
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 Verified as fixed on latest Aurora 26.0a2 (buildID: 20131010004002).
Status: RESOLVED → VERIFIED
status-firefox26: fixed → verified
You need to log in before you can comment on or make changes to this bug.