[
https://issues.apache.org/jira/browse/HADOOP-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryn Sharp updated HADOOP-8999:
--------------------------------
Attachment: HADOOP-8999.patch
Fixing this issue "correctly" by always ending the SASL handshake with a
success/failure introduces an rpc incompatibility. Purely for short-term
compatibility, the rpc server will send a final success response to the client
if and only if the SASL method is PLAIN. The client code is also changed to
ensure that at least one rpc response is always read.
The reason why the currently supported KERBEROS and DIGEST methods work is they
exchange multiple challenge/responses. This guarantees an exception response
or a switch-to-simple message will be read since they will tend to occur on the
first exchange.
The PLAIN method however involves a single exchange. The client sends an
initial response and considers itself done - which means no rpc response will
be read. The server handles the response and also considers itself done.
However, the server may have responded with an exception or a switch to simple
message. But the client won't read it until the next proxy call where it will
generate a protobuf exception.
Hence why this patch forces the server to send a success response for PLAIN,
and to require the client to read at least one rpc so it can read the success
or error message from the server.
In the long term, the server should always send a final success response for
authentication. Ideally there should also be an intermediate RPC state for
SASL to disambiguate if negotiation is occurring or has completed.
> SASL negotiation is flawed
> --------------------------
>
> Key: HADOOP-8999
> URL: https://issues.apache.org/jira/browse/HADOOP-8999
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: ipc
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HADOOP-8999.patch
>
>
> The RPC protocol used for SASL negotiation is flawed. The server's RPC
> response contains the next SASL challenge token, but a SASL server can return
> null (I'm done) or a N-many byte challenge. The server currently will not
> send a RPC success response to the client if the SASL server returns null,
> which causes the client to hang until it times out.
--
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
