JDK-7171399 : Applet throws AccessControlException sporadically while reading user.home
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u27,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_7
  • CPU: generic,x86
  • Submitted: 2012-05-24
  • Updated: 2013-12-13
  • Resolved: 2012-08-21
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u34Fixed 7u10Fixed 8Fixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
Java Plug-in 10.3.0.5
Using JRE version 1.7.0_03-b05 Java HotSpot(TM) Client VM
and
JRE version 1.7.0_04

ADDITIONAL OS VERSION INFORMATION :
Windows 7 32 bit

A DESCRIPTION OF THE PROBLEM :
I am running a applet and one of the class is reading  use.home (System.getProperty("user.home");)

This code is executing this code few times and  it is throwing AccessControlException on irregular interval .

It working most of the time and it fails sporadically and it lead to the application crash.

It is not reproducible with JRE1.6 and 1.5


REGRESSION.  Last worked in version 6u31


ERROR MESSAGES/STACK TRACES THAT OCCUR :
ava.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.home" "read")
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
	at java.lang.System.getProperty(Unknown Source)
	at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.init(Unknown Source)
	at com.documentum.web.applet.ucfinvoker.LaunchRuntime.init(Unknown Source)
	at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
 try
      {
         System.getProperty("user.home");
      
      }
      catch(AccessControlException securityEx)
      {
 
     }
---------- END SOURCE ----------
SHORT SUMMARY: When several signed applets are simultaneously loaded
  from the same web page, some of them may not get full permissions.
INDICATORS: Different kinds of AccessControlException's that are not
  supposed to be thrown for signed applets (for example, on reading
  "user.home" property, or on accessing a local file system).
TRIGGERS: The problem happens sporadically and have symptoms of
  a race condition with low-to-medium failure rate.
KNOWN WORKAROUND: Though there is no direct relation between this change
  and the problem's root cause, disabling the Java Deployment Cache helps
  to avoid the problem.
PRESENT SINCE: Introduction of plugin2, at least.
HOW TO VERIFY: There is no stand-alone test case for this issue.
  The customer verifies the provided binaries in their environment
  and informs us about the verification results.
REGRESSION: No.

Comments
Verified this particular fix but noticed some other issues while running some scenarios. Separate bug will be opened to track the newly noticed issues
2013-12-13

EVALUATION According to the logs provided by the customer plugin2 agrees to grant full permissions to both applets being loaded, i.e. their certificates are accepted. But in fact just one applet has java.security.AllPermission in its associated ProtectionDomain, and the other applet hasn't. It means that the source of the problem is narrowed down to CeilingPolicy.addTrustedPermissions() method that adds to the given list of permissions a set corresponding to trusted code (in most cases this is java.security.AllPermission). Checking this method, I realized that it is not thread-safe. When it is called simultaneously by two different class loaders for two different applets, it may fail - and it seems this is just what happens in the customer's application. I have no idea why it happens with plugin2 and disabled Java Deployment Cache only. Since we deal with a race here, any subtle environment or use case change may influence the behavior and results. The fix is to make that method thread-safe.
2012-07-30

EVALUATION this is not a bug - if the applet code is unsigned, it runs in sandbox and will not have permission to read system property user.home. http://docs.oracle.com/javase/tutorial/deployment/doingMoreWithRIA/properties.html
2012-06-05

PUBLIC COMMENTS In further testing, the customer reports that they have seen the issue with 6u27 as well as 6u31.
2012-06-05

EVALUATION When call System.getProperty(), if there is a security manager, its checkPropertyAccess method is called with the key as its argument. This may result in a SecurityException. From the bug description, the access to "user.home" does not granted the proper permission. Normally, it is the expected behavior to run into AccessControlException. It may be not a bug. Redirect to plugin2 for further evaluation in case there are any changes recently related to the behavior.
2012-05-24