JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-03-23
  • Updated: 2017-05-17
  • Resolved: 2015-05-12
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 b65Fixed
Related Reports
Relates :  
JDK-4202504 - Should allow policy class to be provided as an extension or on CLASSPATH
Relates :  
JDK-8040059 - Change default policy for extensions to no permission
Relates :  
JDK-8057646 - ClassCircularityError running SQE test
Sub Tasks
JDK-8177415 :  
Release Note: Custom Policy Providers may need additional configuration - Closed
Description
If the system property policy.provider is set then the Policy class attempts to load the provider via the boot loader and if that fails, attempts the extension loader. The implementation needs to be re-examined to see how this should work in JDK 9 and modules. 

For starters, the extension mechanism is removed so there isn't a way for 3rd party policy providers to be loaded via the current mechanism. Is there any reason why the current mechanism can't always use the system class loader as the initiating loader? If the loader isn't null then the code could install the bootstrap provider before instantiating the configured policy provider.

It would also be useful if java.security.Policy should specify how it locates the configured provider, I was unable to find anything on this in the javadoc.

Finally, Policy will need to be examined to see if, or how, it should work when then policy provider is in a module.


A thread discussing this topic is here:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-March/004260.html
Comments
The implementation will be adjusted to use the system class loader to find the policy provider. A sentence will be added to the Policy class summary and the java.security file noting that the system class loader is used to locate the policy provider.
01-05-2015
See JDK-4202504 for a previous bug that also tried to fix this issue. Looks like the fix only allowed the provider to be an extension and was never completed to allow the provider to be on classpath. Not sure why or if it was simply an oversight.
21-04-2015
We should also examine the robustness of PolicyFile initialization and probably good to examine together with the custom Security Manager. PolicyFile must complete initialization before any permission check can be performed and separate the error handling from the PolicyFile instantiation. For example, JDK-8057646 shows the ClassCircularityError when PolicyParser fails to parse the input policy file due to e.g. syntax error, the current implementation will format the exception message for localization. Another piece of relevant information. A custom security manager during system initialization will perform permission check to ensure that custom security manager class must have all permissions (System.setSecurityManager0) to catch the recursive initialization issue. Currently the security manager is set before the system class loader is set. This seems the right order of sequence as the (custom) system class loader may perform security sensitive operations.
30-03-2015