[
https://issues.apache.org/jira/browse/HDFS-13951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646710#comment-16646710
]
Daryn Sharp commented on HDFS-13951:
------------------------------------
Given the recent compatibility squabbles, in 2012 (post-MAPREDUCE-4148) I
should have posted my patch that fixed fetchdt to simply let the Token, not the
identifier, beautifully stringify itself. It's what job submission and task
startup use to very neatly print the kind, service, and either the decoded
identifier if possible or a hex string. Instead of blowing up like this
command.
+1 but it would be great if we can abandon this broken hdfs command. A token
fetcher should be in common and can just stringify the token. After the
DelegationTokenIssuer interface is integrated, it could even work for the kms
and other clients.
> HDFS DelegationTokenFetcher can't print non-HDFS tokens in a tokenfile
> ----------------------------------------------------------------------
>
> Key: HDFS-13951
> URL: https://issues.apache.org/jira/browse/HDFS-13951
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: tools
> Affects Versions: 3.2.0
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Attachments: HDFS-13951-001.patch
>
>
> the fetchdt command can fetch tokens for filesystems other than hdfs (s3a,
> abfs, etc), but it can't print them, as it assumes all tokens in the file are
> subclasses of
> {{org.apache.hadoop.hdfs.security.token.delegation.DelegationTokenIdentifier}}
> & uses this fact in its decoding. It deserializes the token byte array
> without checking kind and so ends up with invalid data.
> Fix: ask the tokens to decode themselves; only call toStableString() if an
> HDFS token.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
