JDK-5038176 : security policy runtime settings not working for applets
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_04
  • Priority: P1
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-04-27
  • Updated: 2004-05-06
  • Resolved: 2004-05-06
Related Reports
Relates :  
JDK-4745222 - 1.4 REGRESSION: java.awt.Container.add is very slow in Applets
Description
The customer upgraded to 1.4.2_04 since a z-order panel switching problem has been fixed here.
But their application does not seem to be working any more.The runtime settings are not taking effect.
The Runtime permissions set using the .java.policy are not found to be taking effect. The error
received in java console is
[java.security.AccessControlException: access denied
(javax.security.auth.AuthPermission createLoginContext)]

The policy file for the application has
  permission javax.security.auth.AuthPermission "createLoginContext";

Attached is a sample applet which needs a run time permission and
property permission. Steps to be followed are

1. Extract the zip file
2. Put the html and jar files in any web server 
3. Edit the machine name and port number in .java.policy file
4. Add/Modify the policy file in your user_home/java_home directory
5. Access TestApplet.html in IE where j2re1.4.0_04 plugin is installed
6. Click on Test button.

You can see that the property permissions are granted whereas the
runtime permission is not.
###@###.### 2004-04-27
###@###.### 2004-04-27
###@###.### 2004-04-29
Comments
EVALUATION This is because of introducing security restrcitions for JavaScript->Java calls. Since we cannot verify the origin of JavaScript, the Java code called from the JavaScript is not considered to be from the same codebase. Hence the permissions granted for the applet codebase in java.policy file is not honored in JS->Java call It should work fine if you change the java.policy file to grant the required permissions to all the codebases, for example grant { }; ###@###.### 2004-04-27 I discussed this with security team and found that the customer could resolve this issue by having doPrivliged blocks in the Java code called by JavaScript. In this case the Java code could be given the appropriate permissions either by signing the applet or adding permissions in java.policy file Sample code: void m() { AccessController.doPrivileged( new PrivilegedExceptionAction() { public Object run() { //Do actions that require permissions } }); } ###@###.### 2004-05-06
06-05-2004