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)
