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)