mkazia commented on pull request #1565: URL: https://github.com/apache/hbase/pull/1565#issuecomment-620229753
@joshelser Thanks for your continued indulgence in this. So far from IBM I have managed to find this example > The mechanism expects the calling threads Subject to contain the clients Kerberos credentials or that the credentials could be obtained by implicitly logging in to Kerberos. To obtain the clients Kerberos credentials, use the Java™ Authentication and Authorization Service (JAAS) to log in using the Kerberos login module. See the Java GSS-API and JAAS Tutorials for Use with Kerberos for details and examples. After using JAAS authentication to obtain the Kerberos credentials, you put the code that uses the SASL GSSAPI mechanism within doAs or doAsPrivileged. The example that follows shows the `Sasl.createSaslClient` wrapped in doAs. You can find it all here: https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/saslDocs/clientmechanisms.html?view=embed#clientmechanisms__gssapi The reason why OpenJDK does not need this for creating SaslClient is because it does not call `secCtx.initSecContext()` in the constructor of class [com.sun.security.sasl.gsskerb.GssKrb5Client](https://github.com/openjdk/jdk/blob/master/src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java#L94-L165) which is what gets called when `Sasl.createSaslClient` gets called with GSSAPI mech. Since OpenJDK uses SunSASL and IBM uses IBMSASL, I would imagine they are both different implementations and IBM SASL is possibly calling `secCtx.initSecContext()`. The stack trace show it is calling `com.ibm.security.jgss.GSSManagerImpl.createContext` which I would assume is something similar to `secCtx.initSecContext()` In the absence of IBM JDK source code or proper documentation that shows what the differences are between JDKs, I can only show you by experimentation or by finding precedences. So far I have: 1. Used a bare bone standalone SaslClient code and demonstrated that while the code runs in Oracle/Open JDK it fails in IBM JDK when the SaslClient creation is not wrapped in doAs. I have also shown that wrapping SaslClient creation in doAs works for all 3 JDKs for this example. 2. By way of precedence I have shown that the SaslClient creation code in HDFS client is wrapped in doAs. 3. By way of precedence I have shown that the SaslClient creation code in Hive jdbc client is wrapped in doAs. 4. The application of this patch itself fixes the issue in HBase client for IBM JDK and does not break anything for other JDKs. I hope I have answered the questions to your satisfaction. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
