Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Tue, 29 Jul 2014 22:25:39 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12727654.1405517114053.70473.1406672739173@arcas>
In-Reply-To: <JIRA.12727654.1405517114053@arcas>
References: <JIRA.12727654.1405517114053@arcas>
Subject: [jira] [Commented] (HADOOP-10850) KerberosAuthenticator should not
 do the SPNEGO handshake
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-10850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078501#comment-14078501 ] 

Daryn Sharp commented on HADOOP-10850:
--------------------------------------

I think you are looking too deep.  Here's slightly condensed code for how the white/black list is populated.  Negotiator.getNegotiator must return null to blacklist.

NegotiateAuthentication:
{code}
        Negotiator neg = Negotiator.getNegotiator(hci);
        if (neg != null) {
            supported.put(hostname, true);
            cache.put(hostname, neg);
            return true;
        } else {
            supported.put(hostname, false);
            return false;
        }
{code}

Here's the relevant part of Negotiator.getNegotiator.  Null (blacklist) is only returned for ClassNotFoundException or ReflectiveOperationException.  Otherwise an instance is returned (whitelist), or a different exception is thrown (no action).  The snippet of code you posted is invoked via the ctor called by c.newInstance.  Any exception will rip up the stack w/o updating the white/black list.
{code}
        try {
            clazz = Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null);
            c = clazz.getConstructor(HttpCallerInfo.class);
        } catch (ClassNotFoundException cnfe) {
            return null;
        } catch (ReflectiveOperationException roe) {
            throw new AssertionError(roe);
        }

        try {
            return (Negotiator) (c.newInstance(hci));
        } catch (ReflectiveOperationException roe) {
            return null;
        }
{code}

I don't doubt you saw an issue, but are you sure it's due to blacklisting?  If yes, did the test maybe tinker with class loaders?  Otherwise it would require a ReflectiveOperationException originating in the GSS code.

More likely you saw manifestations of bugs in {{AuthenticatedURL}} that caused me to remove it from webhdfs.

> KerberosAuthenticator should not do the SPNEGO handshake
> --------------------------------------------------------
>
>                 Key: HADOOP-10850
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10850
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.4.1
>            Reporter: Alejandro Abdelnur
>            Assignee: Alejandro Abdelnur
>
> As mentioned in HADOOP-10453, the JDK automatically does a SPNEGO handshake when opening a connection with a URL within a Kerberos login context, there is no need to do the SPNEGO handshake in the {{KerberosAuthenticator}}, simply extract the auth token (hadoop-auth cookie) and do the fallback if necessary.


--
This message was sent by Atlassian JIRA
(v6.2#6252)