Local file access change with new Java update

[Joshua Smith]

If you are following the thread, it sounds like Oracle is pretty hostile to this mode of operation (and I can't say I blame them, as it does seem next-to-impossible to allow applets work work properly with the local file system without at the same time losing much of the security sandbox). I'd be really hesitant to suggest that regular users start doing things in their policy files that open them up to security vulnerabilities.

Since this really only applies to developers, and you can't use chrome properly from the file system anyway (it doesn't have a "Disable Local File Restrictions" checkbox like Safari does), I think requiring that users access these files through a local web server is not that big a deal.

-Joshua

On Jul 9, 2013, at 12:31 AM, Kaydell Leavitt <kaydell.leavitt at icloud.com> wrote:

> Hi Joshua,
> 
>> 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:
> 
> 
> Wouldn't it work for your users to install a policy file, granting them permissions to do what they need to do?
> 
> Or, using the "policytool" command from the command-line to enable applets to do more than the default permissions allow?
> 
> -- Kaydell
> kaydell.leavitt at icloud.com
> http://learnbymac.com
> 
> 
> 
> 
> On Jul 8, 2013, at 9: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
>> 
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Java-dev mailing list      (Java-dev at lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/java-dev/kaydell.leavitt%40icloud.com
>> 
>> This email sent to kaydell.leavitt at icloud.com
>