JDK-8159752 : Grant de-privileged module permissions by default with java.security.policy override option
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-06-16
  • Updated: 2019-03-19
  • Resolved: 2016-07-29
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 9
9 b130Fixed
Related Reports
Blocks :  
JDK-8159528 - Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.auth
Relates :  
JDK-8164071 - Default.policy file missing content for solaris
Relates :  
JDK-8162882 - Permission merge issue in jdk.crypto.ucrypto module
Relates :  
JDK-8218618 - Program fails when using JDK addressed by UNC path and using Security Manager
Relates :  
JDK-8040059 - Change default policy for extensions to no permission
Relates :  
JDK-8080294 - Modularize java.policy files
Relates :  
JDK-8162619 - Doc changes for JDK-8159752
Sub Tasks
JDK-8161307 :  
Release Note: De-privileged module permissions granted by default - Closed
Description
JDK-8040059 changes the default policy for the deprivileged modules (those defined to the platform class loader) to enable granting specific permissions rather than AllPermission.

Setting -Djava.security.policy==override.policy with double equals sign overrides the system security policy that may not work in JDK 9 if the application uses any deprivileged modules. 

Weblogic tests happens to override the security policy with double equals while it is unclear whether it is intended to override than augmenting.

This issue is created to re-evaluate the compatibility risk for JDK-8040059.  The platform class loader only defines JDK modules and JavaFX modules.   One reasonable change may be to separate the security policy for the system modules from ${JAVA_HOME}/conf/security/java.policy.   It should always grant the policy for the system modules unless the same code source is specified in java.policy (either the system-wide one or the one specified in java.security.policy system property)
Comments
One possible approach is to modularize java.policy. Each module can contain src/$MODULE/share/conf/security/java.policy or src/$MODULE/$OS/conf/security/java.policy It should only contain the entry for that module. It will be included in JMOD file. At link time, they should be concatenated to create $JAVA_HOME/conf/security/java.policy - this will solve the problem with the image���s java.policy containing extra entries. During exploded build, it can generate $JAVA_HOME/conf/security/java.policy (not part of any JMOD file) by concatenating java.policy for all modules with patching the code source to replace ���jrt:��� with ���${java.home}/lib/modules/��� something. At runtime, for non-override case, ${JAVA_HOME}/conf/security/java.policy will be read. For the override case -Djava.security.policy==<override.policy>, <override.policy> will be read first. It then uses ModuleReader to read $MODULE/conf/security/java.policy from the image and parse them in the same way as the augmenting case, if no such code source is specified in <override.policy>.
17-06-2016