RFR: 8154009: Some methods of java.security.Security require more permissions, than necessary

Artem Kosarev artem.kosarev at oracle.com
Mon May 30 13:03:51 UTC 2016


Hello.

Could you please review the proposed fix issue which is NOT applicable 
for JDK 9:

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154009
WEBREV: http://cr.openjdk.java.net/~akosarev/8154009/webrev.00/

PROBLEM:
**/AddProvider/, /RemoveProvider///& /GetProviders///methods 
of*//**/java.security.Security/* class results in calling 
/doLoadProvider /method of *ProviderConfig *class for each Security 
Provider.
     And in this method we have a problem that it catches and processes 
*Exception*, but doesn't process *ExceptionInInitializerError *which is 
thrown in case of missing permissions:
             permission java.lang.RuntimePermission "loadLibrary.*";
             permission java.io.FilePermission "<<ALL FILES>>", "read";
             permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.*";
     Those permissions are unavailable if we switch-off 
*jre/lib/security/java.policy* file by running program with option: 
/-Djava.security.policy==<policy_file>/

FIX:
     In JDK9 *ProviderConfig *class is changed in the scope of 
JDK-8043406 <https://bugs.openjdk.java.net/browse/JDK-8043406> 
enhancement (that is why JDK-8154009 is not applicable for JDK 9).
     And in order to fix above problem in JDK 8 we just require to take 
same changes for *ProviderConfig *class in JDK 9:
     See changeset from JDK 9:
http://hg.openjdk.java.net/jdk9/dev/jdk/diff/7f8294841146/src/share/classes/sun/security/jca/ProviderConfig.java

REGRESSION TESTS:
     2 existing tests (*AddProvider*, *RemoveStaticProvider*) were used 
and modified so that they provide testing for fixed situation 
(additional permissions are not required any longer for /AddProvider 
/&**/RemoveProvider /methods.)
     1 new test was written for checking /GetProviders /method under 
restricted permissions.

Changes were successfully tested by JPRT.

Best regards,
Artem Kosarev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160530/6db4a2df/attachment.htm>


More information about the security-dev mailing list