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] [Created] (HADOOP-9034) SASL negotiation is insufficient to support all types
Date Tue, 13 Nov 2012 17:08:12 GMT
Daryn Sharp created HADOOP-9034:

             Summary: SASL negotiation is insufficient to support all types
                 Key: HADOOP-9034
                 URL: https://issues.apache.org/jira/browse/HADOOP-9034
             Project: Hadoop Common
          Issue Type: Bug
          Components: ipc, security
    Affects Versions: 2.0.0-alpha, 0.23.0, 3.0.0
            Reporter: Daryn Sharp

A SASL negotiation requires a series of 1 or more challenge/responses.  The current server-side
RPC SASL implementation may respond with another challenge, an exception, or a switch to simple
method.  The server does not reply when the authentication handshake is complete.

For SASL mechanisms that require multiple exchanges before the client believes the authentication
is complete, the client has an opportunity to read the exception or switch to simple.  However
some mechanisms, ex. PLAIN, consider the exchange complete as soon as it sends the initial
response.  The following proxy call will read the SASL response and throw an incomplete protobuf
exception.  The same issue may manifest when a client sends the final response for a multi-exchange
mechanism and the server returns an exception.

Fixing the problem requires breaking RPC compatibility.  We should consider having the SASL
server always return success when authentication is complete.  HADOOP-8999 added a short-term
workaround to send a success response only for PLAIN, and for the client to always read at
least one RPC response to ensure PLAIN will work.  Another complication is a SASL server returns
non-null when initiating another challenge and null when authentication is established.  However,
the current RPC exchange does not allow a zero-byte response ("client, you initiate the exchange")
to be differentiated from a null ("client, we're authenticated!").  We should consider using
a different RPC status to indicate SASL authentication is in progress, so a zero-byte RPC
success is interpreted as authentication is complete.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message