Local file access change with new Java update

[Gregg Wonderly]

Joe, which security issue does disallowing local access to a filesystem loaded web page address?  It seems like a horrible limitation for developers to work around.  I appreciate that there are things that the security manager needs to do better in this regard, but I'm not at all sure why this needed to be changed.   Is there a bug report or other history/discussion to read about this via?

Gregg Wonderly

On Jul 8, 2013, at 11:59 AM, Joe McGlynn <joe.mcglynn at oracle.com> wrote:

> This is the expected behavior.  
> -- 
> On Jul 8, 2013, at 8:16 AM, Joshua Smith <jesmith at kaon.com> wrote:
> 
>> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update:
>> 
>> Java Plug-in 10.25.2.15
>> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM
>> 
>> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result.
>> 
>> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get:
>> 
>> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read")
>> 
>> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran.
>> 
>> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that.
>> 
>> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to.
>> 
>> -Joshua
>> 
>