[
https://issues.apache.org/jira/browse/HADOOP-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14287006#comment-14287006
]
Hadoop QA commented on HADOOP-11467:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12693817/HADOOP-11467.001.patch
against trunk revision 786dbdf.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-auth.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5448//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/5448//console
This message is automatically generated.
> 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
>
>
> 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)
