-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JTreg security test fails due to unexpected 401 return code from test server #2990
Comments
Will take a look at it |
Do you know if OpenJ9 ever pass this test ? @ben-walsh |
Probably not, this is the first attempt at Java 11 testing. You could try other versions of Java. |
This test failed due to the falling call returning null |
Also failed on OpenJ9 Java 8. |
@hangshao0 Potentially not. Reason this group of tests including this one is being run, is because a couple of them were adapted for TLS 1.3 support for Java 11 and it was a small additional effort to run the entire group under the Java 11 testing. |
Compared the passing and failing outputs, didn't find any clue, |
Note: the security code in question all from OpenJDK, there was no J9 security code involved. @hangshao0 could you post the exception within the test output from both |
I see trace points:
Password was initially set to correct value, then it is set to null. |
The call stack that overwrites the initial password to null is:
|
|
Try using the java debugger to step through the code and see why the password gets set to null, |
Tested on RI, Password will only be set once (to the correct value). I have compared the parameters passed to javax.security.auth.Subject.doAs(), they are essentially the same. The difference is that OpenJ9 calls into PasswordCallback.setPassword() from javax.security.auth.Subject.doAs() and RI does not. |
Where does the null password come from? i.e. does the PasswordAuthentication instance come back as null in the NegotiateCallbackHandler.handle() call? How does the valid password get set? Basically where does OpenJ9 start to differ in the code being run from what the RI is doing? |
From the trace points, I don't see the call to getPassword() after requestPasswordAuthenticationInstance(), so PasswordAuthentication instance in null.
It is set by:
Still trying to figure it out. |
The null PasswordAuthentication instance is from HttpNegotiateServer.java:
|
I'm guessing the problem is in the following area, my assumption being that it should find the existing ticket from the original login, but doesn't.
|
Subject.getSubject(acc) returns null on OpenJ9, it returns a valid subject on RI |
OpenJ9 and RI starts to differ from here in Subject.getSubject():
|
The parameter acc passed to Subject.getSubject(acc) is originally from AccessController.getContext(). OpenJ9 has its own implementation of AccessController.java and AccessControlContext.java, which is likely the root cause of this failure. |
@JasonFengJ9 please help determine why the DomainCombiner is being lost. |
The problem is during enumerating
This is not a proper fix but indeed shows where is the problem and the direction for actual fix. |
This test fails in same way on OpenJDK8+OpenJ9 ...
|
Fails to compile on latest IBM Java 8 SDK ...
|
When the "sub-test" test8077155 is removed from execution, the test passes against OpenJDK11+OpenJ9. For clarity - test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java was only run this time as a check for any regressions resulting from adding the TLS 1.3 support - it is not explicitly testing TLS 1.3 support. Considering this and the other evidence above, I DO NOT consider that this issue should delay the OpenJDK11+OpenJ9 release any further. |
I'll just note this issue in particular is not delaying the release, there are other issues in the release plan https://github.com/eclipse/openj9/milestone/3 |
Test test8077155 of test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java fails with the following exception stack when run against OpenJ9. No such error occurs when run against Hotspot ...
The unexpected 401 response code is returned from the test server despite using the correct username and password to authenticate.
This is a regression test added alongisde the fix that went in for this OpenJDK bug - https://bugs.openjdk.java.net/browse/JDK-8077155
OpenJ9 build tested with ...
Hotspot build test with ...
Full archive of JTreg logs :
HNSFailure.tar.gz
The text was updated successfully, but these errors were encountered: