hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10850) KerberosAuthenticator should not do the SPNEGO handshake
Date Tue, 29 Jul 2014 22:25:39 GMT

    [ 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)

Mime
View raw message