United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7171399 : Applet throws AccessControlException sporadically while reading user.home

Details
Type:
Bug
Submit Date:
2012-05-24
Status:
Closed
Updated Date:
2013-12-13
Project Name:
JDK
Resolved Date:
2012-08-21
Component:
deploy
OS:
generic,windows_7
Sub-Component:
deployment_toolkit
CPU:
generic,x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u27,7
Fixed Versions:
7u6 (b31)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

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



Hardware and Software, Engineered to Work Together