Our signed applet has been giving us the error "java.security.AccessControlException: access denied java.io.FilePermission" since update 24 of Java ( JRE version 1.6.0_24-b07 ).
Our policy file goes as follow:
Our certificate is supposed to be valid until March 2012.
Has anybody an idea about what's going on with the update?
I don't know if it's useful information, but the error is given when trying to read the app roaming folder:
Which doesn't seem to exist (C:\Users\username\AppData\Roaming\Microsoft\Windows\Recent Items does however). I didn't find any explicit references to these folders in our code, but I'll keep looking.
My signed applet is getting ...
java.lang.SecurityException: Permission denied: file:/C:/Documents and Settings/All Users/Application Data/IBMERS/IBM GERS Release 1.6 - Core - MAC/
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
since updating to ...
Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
All was fine until the update.
We have a class 3 code signing certificate from verisign and are seeing this issue with 1.6.0_24. We have not had an issue previously. For paranoia's sake we re-signed the applet's jar with 1.6.0_24 and it made no difference. We are seeing a java.security.AccessControlException: access denied (java.awt.AWTPermission listenToAllAWTEvents) as well.
Explicitly adding an entry to java.policy is a workaround, but it's not terribly feasible given we have customers worldwide.
I'm not saying that you all are incorrect in calling this a bug, but keep one thing in mind: Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn't be surprised if Oracle takes the policy of security first, compatibility second.
Of course it would be nice if such things are documented.
Did some more testing ...
My applet is a signed client / server applet. We download the applet to the user's hard drive so that the application can be run in an "offline" mode.
I was looking at our <applet> specifications and our applet <param> specification.
We use <param name="codebase" to point where the applet was installed on the hard drive. If I comment out the "codebase", the applet runs fine.
Correct if I'm wrong, but eliminating the "codebase" then tells Java to go look for that jar file, on the server, where the current HTML page was served from. Our jar file, that we download, just so happens to be in the same directory.
So ... with Update 24, execution is not a problem when loading and running the applet from the server, but trying to load and run the applet from the hard drive is now a problem which previously was not a problem. This definitely breaks our need for our users to run "offline"
For the life of me, I can't find anything in the "changes" to Update 24 that would explain why this is happening or why they would consider this type of execution a security concern.
Edited by: 837423 on Feb 17, 2011 11:41 AM
They already create a new bug in their internal bug tracking system (Bug Id: 7020285). It may take a day or two before this bug shows up in the external database.
You can monitor this bug on the Java Bug Database at
In order to do offline mode, every bits needs to be on the local system, including the html/js loaded by the browser.
If I understand you correctly, you are trying to load the html via browser, using a http URL, e.g:
And inside applet.html, you have codebase pointing to c:\some_files
This will not work due to security reasons. And most browser blocks this too, e.g:
won't load either by a browser, if the html is loaded via http://your_host.com/img.html
So if you want to use codebase with a local path, your browser html/js file itself needs to be loaded from the local file system too.