JDK-8224635 : Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-05-23
  • Updated: 2019-06-29
  • Resolved: 2019-05-23
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 13
13 b23Fixed
Related Reports
Relates :  
JDK-8224656 - Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed
Relates :  
JDK-8224256 - test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1
Relates :  
JDK-8224685 - test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1 - try #2
Sub Tasks
JDK-8224656 :  
Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed - Resolved
Description
Test java/security/SecureClassLoader/DefineClass.java is failing after JDK-8224256

----------System.err:(14/874)---------- 
java.lang.Exception: Granted permissions not correct 
at DefineClass.checkPerms(DefineClass.java:201) 
at DefineClass.main(DefineClass.java:166) 
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567) 
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830) 

JavaTest Message: Test threw exception: java.lang.Exception: Granted permissions not correct 
JavaTest Message: shutting down test
Comments
Verified it by running test java/security/SecureClassLoader/DefineClass.java with jdk13+27 on macosx.
29-06-2019
[~aeubanks] The linux machines have IPv6, it's just that the IPv6 loopback isn't configured to map to the name "localhost". Permissions may only do string comparisons - maybe there's a special hack for 127.0.0.1 somewhere, I don't know - hard to say without investigating further! Unfortunately for the one solaris failure I observed, that was before adding my debug prints - so I have no idea what was the config there. Additional piece of the puzzle: some of the linux test machines report: localhost: [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] and in that case, the test pass.
23-05-2019
Ok I will revert the change to the test.
23-05-2019
If the Linux machines in the test farm don't have IPv6, then this code path in the test shouldn't be run, so I'm surprised the error appears in the IPv6 code path. IPSupport.hasIPv6 returns true when it can bind to a socket at [::1]. So maybe like you said, the localhost config is wrong for the Linux machines. Regarding flaky Solaris test failures, is it possible that different Solaris machines in the test farm are setup differently? e.g. some have IPv6 and some don't? Or maybe the same as above with a weird localhost config? The Windows one makes less sense, localhost does map to [::1] but the permissions checker doesn't see it?
23-05-2019
If this is going to take a while to evaluate, my preference would be to restore the test to its previous state, remove it from the ProblemList and re-open the original issue. I would rather not keep this test on the ProblemList as we get closer to RDP1/RDP2.
23-05-2019
The submit repo only run tier1 tests. Networking tests are in tier2 (and security tests as well I believe). There may be two different issues: the reason why it fails on linux may be different from the reason it fails on windows. I mean, maybe it fails on linux because of the localhost config - which lists only the IPv4 loopback. Maybe it fails on windows for a different reason.
23-05-2019
It still doesn't fail on my Linux machine (even with the LD_PRELOAD to force IPv6 only), so I'll have to figure out an environment to get this to fail. jshell> InetAddress.getAllByName("localhost") $1 ==> InetAddress[2] { localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1 } Also, I did run this through the submit repo and got results saying everything was good, is this test not part of mach5?
23-05-2019
System.out.println("localhost: " + Arrays.asList(InetAddress.getAllByName("localhost"))) prints: - On my own Mac: localhost: [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1, localhost/fe80:0:0:0:0:0:0:1%1] - In the test farm: Linux: localhost: [localhost/127.0.0.1] Solaris: localhost: [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] Windows: localhost: [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] Mac: localhost: [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] So there doesn't seem to be a complete correlation there - since the test was failing consistently on both linux *and* windows...
23-05-2019
One way to fix would be to add permission to read user.home to "http://[::1]/" codebase, but I'm not sure we want to do that. It could be a short term solution to take the test out of the problem list. [~mullan] what do you think? (I have tested it and with that the test passes on all platforms. But is that the right fix?)
23-05-2019
Here is how it fails on linux (we get the exact same trace on windows): Perms: [("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*"), ("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*"), ("java.lang.RuntimePermission" "getProtectionDomain"), ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.java.swing.plaf.*"), ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans"), ("java.util.PropertyPermission" "user.name" "read")] Granted Perms: [("java.util.PropertyPermission" "user.home" "read"), ("java.util.PropertyPermission" "user.name" "read")] java.lang.Exception: Granted permissions not correct at DefineClass.checkPerms(DefineClass.java:203) at DefineClass.main(DefineClass.java:166) The issue is that Perms doesn't have ("java.util.PropertyPermission" "user.home" "read") presumably because "127.0.0.1" is recognized as an alias to "localhost" but "[::1]" isn't. I am not sure where to look for...
23-05-2019
The test is failing on linux and windows, and intermittently on solaris. I will problem list it until the root cause can be found.
23-05-2019
+ // For IPSupport + grant codebase "file:${test.classes}/../../../../test/lib/-" { + permission java.net.SocketPermission "localhost:0", "listen,resolve"; + permission java.util.PropertyPermission "java.net.preferIPv4Stack", "read"; + }; what performs the test.classes substitution for the policy file ??
23-05-2019
The discussion on the changes on SecureClassLoader were discussed here: https://mail.openjdk.java.net/pipermail/security-dev/2019-May/019925.html
23-05-2019
Thanks Sean. I have added a System.err.println in my local repo to print the two permissions sets that are compared. I want to see whether the issue is with the permissions granted to the library code.
23-05-2019
The JDK policy provider supports system property substitution so ${test.classes} will be replaced with the value that is set by the jtreg harness. See: https://docs.oracle.com/en/java/javase/12/security/permissions-jdk1.html#GUID-B614FBFF-0C3C-42F3-B766-DE709CA4D73A To debug this, I would run with -Djava.security.debug=access,domain,failure to see how the permissions are being granted. It is interesting that it does not fail consistently across all platforms, so it could be something more subtle.
23-05-2019