You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Yongjun Zhang (JIRA)" <ji...@apache.org> on 2015/01/07 22:30:34 UTC
[jira] [Commented] (HADOOP-11467) KerberosAuthenticator can connect
to a non-secure cluster
[ https://issues.apache.org/jira/browse/HADOOP-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268279#comment-14268279 ]
Yongjun Zhang commented on HADOOP-11467:
----------------------------------------
Thanks Robert for creating the jira, I'm assigning to myself per our discussion.
> 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
> Reporter: Robert Kanter
> Assignee: Yongjun Zhang
> Priority: Critical
>
> 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)