[
https://issues.apache.org/jira/browse/HDFS-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-7367:
--------------------------------
Attachment: HDFS-7367.1.patch
I'm attaching a patch with the simple fix. We just need to check if the
channel is secure/trusted before entering SASL negotiation. As per the
definition of {{DomainPeer#hasSecureChannel}}, traffic over a domain socket is
assumed to be trustworthy, because it doesn't cross a network, and we restrict
the permissions on the domain socket.
I don't have a test yet. I'll look into adding one.
> HDFS short-circuit read cannot negotiate shared memory slot and file
> descriptors when SASL is enabled on DataTransferProtocol.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-7367
> URL: https://issues.apache.org/jira/browse/HDFS-7367
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs-client
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-7367.1.patch
>
>
> When both short-circuit read and SASL on DataTransferProtocol are enabled,
> the server side tries to negotiate SASL on the operation to allocate a new
> shared memory slot. However, the transport for this operation is the Unix
> domain socket (not TCP), and the client always assumes that Unix domain
> socket traffic is trustworthy. The end result is that the server side still
> attempts SASL negotiation, and it fails with an exception while erroneously
> trying to parse the domain socket address as if it were a network address.
> The read succeeds, but only because we fallback to a read through the
> DataNode TCP server. It's not a short-circuit read.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
