[
https://issues.apache.org/jira/browse/HADOOP-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386692#comment-15386692
]
Zhe Zhang commented on HADOOP-13206:
------------------------------------
Thanks much for the suggestion [~cnauroth].
Although in our case the issue happened with 2.6 and 2.3 clients, now I think
it can happen with the same version of client for 2 reasons. Let's assume there
are client {{A}}, which fetches tokens, and client {{B}}, which uses tokens.
# Client {{A}} and client {{B}} could use different values of
{{hadoop.security.token.service.use_ip}}. Should we treat this as a
mis-configuration and enforce the same value across any entire production
environment?
# Client {{A}}, when fetching the token, could use numerical IP address to
refer to the NameNode, such as {{webhdfs://123.45.67.89:50070}}. Client {{B}},
when using the token, could use a logical URI {{webhdfs://clusterNN}}.
Good point about DNS overhead. How about we update the patch and only do the
newly added check if one URI is logical and the other is not?
> Delegation token cannot be fetched and used by different versions of client
> ---------------------------------------------------------------------------
>
> Key: HADOOP-13206
> URL: https://issues.apache.org/jira/browse/HADOOP-13206
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.3.0, 2.6.1
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Attachments: HADOOP-13206.00.patch, HADOOP-13206.01.patch,
> HADOOP-13206.02.patch
>
>
> We have observed that an HDFS delegation token fetched by a 2.3.0 client
> cannot be used by a 2.6.1 client, and vice versa. Through some debugging I
> found that it's a mismatch between the token's {{service}} and the
> {{service}} of the filesystem (e.g. {{webhdfs://host.something.com:50070/}}).
> One would be in numerical IP address and one would be in non-numerical
> hostname format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
