[ 
https://issues.apache.org/jira/browse/HDFS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Nauroth updated HDFS-7073:
--------------------------------
    Attachment: HDFS-7073.3.patch

Thank you for looking again, Yi.  Here is patch v3.  This stops tracking the 
flag per {{Call}} instance.  I don't think we can make the flag a member of 
{{Connection}}.  Because of the {{ClientCache}} and the internal pooling of 
{{Connection}} instances, there could be a risk that one {{DFSClient}} instance 
shuts down, then another {{DFSClient}} instance connects to the same cluster, 
and it ends up pulling a pooled {{Connection}} that still contains the flag 
connected to the old {{DFSClient}}.  It's definitely a good simplification 
though to take your suggestion of not tracking it as a member of {{Call}}.  We 
can just pass it through to {{setupIOstreams}}.

Thanks also for catching the leftover TODOs.  These were already done in the 
prior patch by the code changes in {{AbstractNNFailoverProxyProvider}}, so I 
removed the comments.

> Allow falling back to a non-SASL connection on DataTransferProtocol in 
> several edge cases.
> ------------------------------------------------------------------------------------------
>
>                 Key: HDFS-7073
>                 URL: https://issues.apache.org/jira/browse/HDFS-7073
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode, hdfs-client, security
>            Reporter: Chris Nauroth
>            Assignee: Chris Nauroth
>         Attachments: HDFS-7073.1.patch, HDFS-7073.2.patch, HDFS-7073.3.patch
>
>
> HDFS-2856 implemented general SASL support on DataTransferProtocol.  Part of 
> that work also included a fallback mode in case the remote cluster is running 
> under a different configuration without SASL.  I've discovered a few edge 
> case configurations that this did not support:
> * Cluster is unsecured, but has block access tokens enabled.  This is not 
> something I've seen done in practice, but I've heard historically it has been 
> allowed.  The HDFS-2856 code relied on seeing an empty block access token to 
> trigger fallback, and this doesn't work if the unsecured cluster actually is 
> using block access tokens.
> * The DataNode has an unpublicized testing configuration property that could 
> be used to skip the privileged port check.  However, the HDFS-2856 code is 
> still enforcing requirement of SASL when the ports are not privileged, so 
> this would force existing configurations to make changes to activate SASL.
> This patch will restore the old behavior so that these edge case 
> configurations will continue to work the same way.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to