[
https://issues.apache.org/jira/browse/HDFS-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737914#comment-14737914
]
Yongjun Zhang commented on HDFS-6142:
-------------------------------------
HI [~d.yuan],
Thanks for reporting the issue, and I happen to see it as late as today. Would
you please check if HDFS-6475 fix the problem?
Thanks.
> StandbyException wrapped to InvalidToken exception
> --------------------------------------------------
>
> Key: HDFS-6142
> URL: https://issues.apache.org/jira/browse/HDFS-6142
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 2.2.0
> Reporter: Ding Yuan
>
> The following code in
> org/apache/hadoop/hdfs/security/token/delegation/DelegationTokenSecretManager.java:
> {noformat}
> public byte[] retrievePassword(
> DelegationTokenIdentifier identifier) throws InvalidToken {
> try {
> // this check introduces inconsistency in the authentication to a
> // HA standby NN. non-token auths are allowed into the namespace which
> // decides whether to throw a StandbyException. tokens are a bit
> // different in that a standby may be behind and thus not yet know
> // of all tokens issued by the active NN. the following check does
> // not allow ANY token auth, however it should allow known tokens in
> namesystem.checkOperation(OperationCategory.READ);
> } catch (StandbyException se) {
> // FIXME: this is a hack to get around changing method signatures by
> // tunneling a non-InvalidToken exception as the cause which the
> // RPC server will unwrap before returning to the client
> InvalidToken wrappedStandby = new InvalidToken("StandbyException");
> wrappedStandby.initCause(se);
> throw wrappedStandby;
> }
> return super.retrievePassword(identifier);
> }
> {noformat}
> A StandbyException from namesystem.checkOperation is wrapped to InvalidToken
> exception. The comment suggests that the RPC server will unwrap it to
> StandbyException before sending back to the client, but this may not be the
> case for every code path. For example, in datanode's DataXceiver.copyBlock,
> it will call checkAccess which eventually might call retrievePassword, but
> when copyBlock catches an InvalidToken exception, it would simply send to the
> client that exception without unwrapping it.
> I am not exactly sure about the possible consequence, but it seems client
> treats StandbyException (which is perhaps much more serious) very different
> from InvalidToken exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
