JDK-6559401 : AccessControlException in signed applet(calling File.exists()) when JSObject used
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-18
  • Updated: 2013-09-12
  • Resolved: 2011-04-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Relates :  
Description
J2SE Version (please include all output from java -version flag):
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x or 6.0?  Yes / No (pick one) 
N/A

Operating System Configuration Information (be specific):
Microsoft Windows XP 
Solaris
Linux

Bug Description:

Having a very odd problem with my application.  Up until now, I have focussed on deploying it via 
Java Web Start and it has been fine.  A few months ago, I started deploying as a Java applet, and again, 
it also has been fine.

My application consists of several jars, all of which are signed.  This is necessary because the app 
reads/writes user preferences, and also reads/writes to a file-based cache in the end-user's home folder.  
All of this works fine in the Web Start and Applet environments.

In the last couple of weeks I have been working on a JavaScript api as well, and I am getting 
AccessControlException in the particular case where clicking an HTML button causes the script to 
invoke a Java method. Everything seems to work fine to begin with - the click is clearly getting 
passed through to the "right places", and, so long as no caching is involved it still works fine. 

But, if the JavaScript click causes use of the local file cache, I am getting the AccessControlException 
thrown in a completely separate thread which normally works perfectly ok.  It is as if, the call from 
JavaScript has temporarily removed the jar signature.

Step to reproduce:

Attached a relatively simple test applet.  And here it is on the web site:
    http://limemap.esri.com/javaone/test/js-test-indirect.htm

When it opens, you'll see there are a couple of HTML buttons at the top, and underneath 
is a Java applet with some more buttons a text field and a text area.

Work with the applet first:
    o   type a suitable filename in the text field, see the actual pathname in the label on the right
    o   click the exists button - tells you if it exists or not
    o   click the create button, then exists, then remove then exists to see what happens
    o   during all this, look in the file system and see that the file is created and removed correctly - it is!

Now turn your attention to the HTML buttons:
    o   note that the "Create File" button calls the same applet method as does the applet "create" button
    o   similarly, the "Test Exists" button calls the same applet method as does the applet "exists" button
    o   try each of them, they both throw AccessControlException

So, why does the same code work when it is initiated from within the signed JAR, but not 
when initiated from the javascript?


> ------------------------------------------
>
> JMapr 1.0,  Java 1.5.0_11-b03,  Linux 2.6.20-1.2948.fc6
> 17/05/2007 12:08:05 com.esri.mc.m2d.Map2d a
> SEVERE: com.esri.mc.m2d.Map2d
> java.security.AccessControlException: access denied (java.io.FilePermission /home/russell/.JMapr/2D/www.arcwebservices.com/map-2006-0.0-0.0-158629887-ArcWeb-bam-1969-1795-0.0-svg-nt-53004 read)
>     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
>     at java.security.AccessController.checkPermission(AccessController.java:427)
>     at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>     at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
>     at java.io.File.exists(File.java:700)
>     at com.esri.ox.hc.HttpCache.a(Unknown Source)
>     at com.esri.ox.hc.HttpCache.a(Unknown Source)
>     at com.esri.ox.hc.d.getData(Unknown Source)
>     at com.esri.ox.hc.HttpRetriever.a(Unknown Source)
>     at com.esri.ox.hc.HttpRetriever.a(Unknown Source)
>     at com.esri.ox.hc.a.run(Unknown Source)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>     at java.lang.Thread.run(Thread.java:595)
>

Comments
SUGGESTED FIX This is by design, mark the code priviliged with AccessController.doPriviliged() when appropriate.
08-04-2011

EVALUATION If unsigned code calls into signed and signed need to execute something privileged this is perfectly fine. Should be same for JS. Moreover, JS is used in this way. E.g. Facebook used to have photo upload applet for this reason (applet has more features than plain js). Note that stacktrace does not contain any JS code per se. Everything is coming from bootclasspath or signed applet. So why is this insecure? Could be probably related to 6995087 and 7017729.
17-02-2011

EVALUATION Well, this is what security check suppose to be. The applet security model and Javascript security modal is different, JS never use the Applet privilege, even the signed applet has AllPermissions, but JS won't get those permissions. This is due to security concern. There is some concept for Signed JavaScript, but it is only accept in Mozilla browser family, we are doing some new changed in JDK 7 for Liveconnect, hope we will provide more easy deployment mechanism to user. Therefore I will leave this bug open for now.
21-05-2007