[
https://issues.apache.org/jira/browse/HADOOP-13539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437278#comment-15437278
]
Arun Suresh commented on HADOOP-13539:
--------------------------------------
bq. Also, for DT auth, the token is verified, which eventually checks its
expire time, so I don't think an expired token would work - otherwise we should
fix it as a big security flaw.
IIRC there are 2 cases for removing a Token. a) during expiry and b) when an
explicit cancel is called.
As you pointed out, in case of a), since its an expired token, it wont pass
authentication in any of its peers anyway. But in case of b) which is called
from
[here|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/DelegationTokenAuthenticationHandler.java#L265]
it is important that the token be removed. The KMSClient will usually re-try
on another peer if the operation fails on one ZKDTSM and that process is
brought down, which will hopefully ensure this key is somehow removed.
> KMS's zookeeper-based secret manager should be consistent when failed to
> remove node
> ------------------------------------------------------------------------------------
>
> Key: HADOOP-13539
> URL: https://issues.apache.org/jira/browse/HADOOP-13539
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms
> Affects Versions: 2.6.0
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HADOOP-13539.01.patch
>
>
> In {{ZKDelegationTokenSecretManager}}, the 2 methods
> {{removeStoredMasterKey}} and {{removeStoredToken}} are very much alike, yet
> handles exception differently. We should not throw RTE if a node cannot be
> removed - logging is enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
