[jira] [Created] (HDFS-6142) StandbyException wrapped to InvalidToken exception

["Ding Yuan (JIRA)" <ji...@apache.org>]

Ding Yuan created HDFS-6142:
-------------------------------

             Summary: 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.2#6252)