You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Dan Burkert (JIRA)" <ji...@apache.org> on 2017/08/30 22:10:00 UTC

[jira] [Created] (KUDU-2121) Java Client chooses GSSAPI SASL mechanism when Kerberos credentials are not present

Dan Burkert created KUDU-2121:
---------------------------------

             Summary: Java Client chooses GSSAPI SASL mechanism when Kerberos credentials are not present
                 Key: KUDU-2121
                 URL: https://issues.apache.org/jira/browse/KUDU-2121
             Project: Kudu
          Issue Type: Bug
          Components: java
    Affects Versions: 1.4.0
            Reporter: Dan Burkert


I've found an interesting difference in behavior between macos/Oracle JDK 8.0_144 and Centos 7/OpenJDK 8.0_121 in the [Sasl mechanism choosing code|https://github.com/apache/kudu/blob/2f78643e4979fc8a9499498aa04c7f4ffa0deb61/java/kudu-client/src/main/java/org/apache/kudu/client/Negotiator.java#L358-L389].  On macos, it will not choose GSSAPI if Kerberos credentials aren't present, because Sasl.createSaslClient will throw a SaslException.  On Centos 7 with OpenJDK, GSSAPI _will_ be chosen, and the negotiation will fail during the first call to [saslClient.evaluateChallenge|https://github.com/apache/kudu/blob/2f78643e4979fc8a9499498aa04c7f4ffa0deb61/java/kudu-client/src/main/java/org/apache/kudu/client/Negotiator.java#L680] (again, with a SaslException).  I haven't gotten to the bottom of the difference in behavior, and whether the platform, JDK version, or both is involved.

Practically, the only effect this has is that unauthenticated clients on the Linux/OpenJDK platform will be unable to connect to authentication-optional servers, since the server will present GSSAPI as an option, the client will choose it, and then fail during evalueateChallenge.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)