hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7073) Allow falling back to a non-SASL connection on DataTransferProtocol in several edge cases.
Date Wed, 17 Sep 2014 18:35:34 GMT

    [ https://issues.apache.org/jira/browse/HDFS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137711#comment-14137711
] 

Chris Nauroth commented on HDFS-7073:
-------------------------------------

[~jnp], thank you for taking a look.

Regarding the instanceof check, I don't see a way to avoid it.  There is a lot of existing
logic in the catch clause checking for specific exception types and doing special handling.
 When fallback fails, we need to be able to drive the original exception into this handling
logic to preserve the existing error handling behavior.  Some of this logic controls the outer
loop too ({{break}} vs. {{continue}}), so it's not logic that's trivial to refactor behind
a reusable method.  Maybe this whole code path would benefit from a larger clean-up refactoring,
but that would be too much to fold into this patch now.

Regarding checking {{ignore.secure.ports.for.testing}}, we can't make that change in the client.
 {{ignore.secure.ports.for.testing}} has been a server-side property used by the DataNode
only.  It's possible that the client would be running with different config files than the
DataNode.  If an existing deployment defined {{ignore.secure.ports.for.testing}} in the DataNode
configs, but not the client configs, then this wouldn't work.

On the server side, I'm unclear on exactly what we'd do with a check of {{ignore.secure.ports.for.testing}}.
 If we do {{} else if (ignoreSecurePortsForTesting) {}}, then we'd still need a catch-all
{{else}} block for when both {{dfs.data.transfer.protection}} and {{ignore.secure.ports.for.testing}}
are off.  I suppose the only thing we can do there is to try a no-SASL connection, which is
identical to the handling of the current patch.  Maybe it's actually clearer to leave the
patch as is?

Let me know your thoughts.  Thanks again!

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

Mime
View raw message