JDK-8228440 : TestAESCiphers tests fail with "access denied" trying to access ArrayUtil
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: openjdk8u222
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-19
  • Updated: 2020-02-13
  • Resolved: 2019-09-04
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.
Other
openjdk8u232 b05Fixed
Related Reports
Duplicate :  
JDK-8229658 - Jtreg test TestAESWithProviderChange fails after 8u222
Relates :  
JDK-8179098 - Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)
Description
If you run current 8u tests, then some tests would fail.

Apply this patch to jdk:

diff -r 010d44fe3c85 test/TEST.groups
--- a/test/TEST.groups  Thu Mar 21 21:37:09 2019 -0700
+++ b/test/TEST.groups  Fri Jul 19 16:50:55 2019 +0200
@@ -26,4 +26,7 @@
 #
 
+jdk_test = \
+    com/sun/crypto/provider/Cipher/AES/TestAESCiphers
+
 tier1 = \
     :jdk_lang \

...then run:

CONF=linux-x86_64-normal-server-fastdebug make images test TEST=jdk_test

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
        at java.security.AccessController.checkPermission(AccessController.java:886)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
        at java.lang.ClassLoader$1.run(ClassLoader.java:496)
        at java.lang.ClassLoader$1.run(ClassLoader.java:494)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:494)
        at com.sun.crypto.provider.OutputFeedback.encrypt(OutputFeedback.java:152)
        at com.sun.crypto.provider.CipherCore.update(CipherCore.java:785)
        at com.sun.crypto.provider.AESCipher.engineUpdate(AESCipher.java:410)
        at javax.crypto.Cipher.update(Cipher.java:1944)
        at Dynamic.runTest(Dynamic.java:150)
        at Dynamic.runAllTest(Dynamic.java:89)
        at Dynamic.run(Dynamic.java:59)
        at TestAESWithRemoveAddProvider.main(TestAESWithRemoveAddProvider.java:40)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.lang.Thread.run(Thread.java:748)

...

Summary: jdk_test
FAILED: com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java
FAILED: com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java
TEST STATS: name=jdk_test  run=3  pass=1  fail=2

This seems to be introduced by 8u backport of JDK-8179098:
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/0da125166b2b#l7.22

11u and 12u are fine.
Comments
It turns out that this was more of an issue with the jtreg test case rather than a package access problem at product src level. Code in ext dirs gets all permissions by default as per java.policy file : == // Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; }; == jtreg testcase structure was running with reduced permissions. The /policy jtreg tag [1] overrides the default system policy to use only the policy file specified, so it isn't running the test under typical conditions that a user would. If a test uses its own policy file, then it also has to make sure it grants all of the permissions that the JDK code needs too. [1] https://openjdk.java.net/jtreg/tag-spec.html#ACTION_TAGS suggested (alternative patch) --- a/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java +++ b/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java @@ -27,7 +27,7 @@ * @bug 8044193 * @summary Test AES ciphers with different modes and padding schemes after * remove then add provider. - * @run main/othervm/policy=testAES.policy TestAESWithProviderChange + * @run main/othervm/java.security.policy=testAES.policy TestAESWithProviderChange */ public class TestAESWithProviderChange extends Dynamic { diff --git a/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java b/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java --- a/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java +++ b/test/com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java @@ -29,7 +29,7 @@ * @bug 8044193 * @summary Test AES ciphers with different modes and padding schemes after * remove default provider then add it back. - * @run main/othervm/policy=testAES.policy TestAESWithRemoveAddProvider + * @run main/othervm/java.security.policy=testAES.policy TestAESWithRemoveAddProvider */
13-02-2020
URL: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/d44a3f4b841f User: andrew Date: 2019-09-06 02:14:58 +0000
06-09-2019
URL: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/d44a3f4b841f User: andrew Date: 2019-09-04 04:54:23 +0000
04-09-2019
Fix Request: Package changes are needed to allow the backported code to function when a SecurityManager is in place. In the original patch, OpenJDK 11 uses the module system so the permission requirements are different there.
21-08-2019
RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-July/009851.html
19-07-2019