hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yongjun Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6142) StandbyException wrapped to InvalidToken exception
Date Thu, 10 Sep 2015 00:57:46 GMT

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

Mime
View raw message