[
https://issues.apache.org/jira/browse/HADOOP-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315396#comment-14315396
]
Robert Kanter commented on HADOOP-11467:
----------------------------------------
Looking at
https://builds.apache.org/job/PreCommit-HADOOP-Build/5645//testReport/, it
looks like everything passed so not sure what Jenkins is unhappy with; I've
just retrogressed the job so we can try again.
> KerberosAuthenticator can connect to a non-secure cluster
> ---------------------------------------------------------
>
> Key: HADOOP-11467
> URL: https://issues.apache.org/jira/browse/HADOOP-11467
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.6.0
> Reporter: Robert Kanter
> Assignee: Yongjun Zhang
> Priority: Critical
> Attachments: HADOOP-11467.001.patch, HADOOP-11467.002.patch,
> HADOOP-11467.003.patch, HADOOP-11467.004.patch
>
>
> While looking at HADOOP-10895, we discovered that the
> {{KerberosAuthenticator}} can authenticate with a non-secure cluster, even
> without falling back.
> The problematic code is here:
> {code:java}
> if (conn.getResponseCode() == HttpURLConnection.HTTP_OK) { // <-----
> A
> LOG.debug("JDK performed authentication on our behalf.");
> // If the JDK already did the SPNEGO back-and-forth for
> // us, just pull out the token.
> AuthenticatedURL.extractToken(conn, token);
> return;
> } else if (isNegotiate()) { // <-----
> B
> LOG.debug("Performing our own SPNEGO sequence.");
> doSpnegoSequence(token);
> } else { // <-----
> C
> LOG.debug("Using fallback authenticator sequence.");
> Authenticator auth = getFallBackAuthenticator();
> // Make sure that the fall back authenticator have the same
> // ConnectionConfigurator, since the method might be overridden.
> // Otherwise the fall back authenticator might not have the
> information
> // to make the connection (e.g., SSL certificates)
> auth.setConnectionConfigurator(connConfigurator);
> auth.authenticate(url, token);
> }
> }
> {code}
> Sometimes the JVM does the SPNEGO for us, and path A is used. However, if
> the {{KerberosAuthenticator}} tries to talk to a non-secure cluster, path A
> also succeeds in this case.
> More details can be found in this comment:
> https://issues.apache.org/jira/browse/HADOOP-10895?focusedCommentId=14247476&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14247476
> We've actually dealt with this before. HADOOP-8883 tried to fix a related
> problem by adding another condition to path A that would look for a header.
> However, the JVM hides this header, making path A never occur. We reverted
> this change in HADOOP-10078, and didn't realize that there was still a
> problem until now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
