[
https://issues.apache.org/jira/browse/HADOOP-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14314798#comment-14314798
]
Yongjun Zhang commented on HADOOP-11467:
----------------------------------------
Hi [~rkanter],
Thanks a lot for looking and catching that. Sorry for "losing" the file. I just
uploaded rev 004 to add it.
> 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)
