[
https://issues.apache.org/jira/browse/YARN-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16025503#comment-16025503
]
Jason Lowe commented on YARN-6650:
----------------------------------
The decode then re-encode issue is not really specific to
ContainerTokenIdentifier. Any token that is re-encoded in such a way where
unknown fields are either omitted or not guaranteed to be serialized in the
same order as done by the token creator could be problematic for upgrade
scenarios.
> ContainerTokenIdentifier is re-encoded during token verification
> ----------------------------------------------------------------
>
> Key: YARN-6650
> URL: https://issues.apache.org/jira/browse/YARN-6650
> Project: Hadoop YARN
> Issue Type: Bug
> Components: security
> Affects Versions: 2.8.0
> Reporter: Jason Lowe
>
> A ContainerTokenIdentifier is serialized into bytes and signed by the RM
> secret key. When the NM needs to verify the identifier, it is decoding the
> bytes into a ContainerTokenIdentifier to get the key ID then re-encoding the
> identifier into a byte buffer to hash it with the key. This is fine as long
> as the RM and NM both agree how a ContainerTokenIdentifier should be
> serialized into bytes.
> However when the versions of the RM and NM are different and fields were
> added to the identifier between those versions then the NM may end up
> re-serializing the fields in a different order than the RM did, especially
> when there were gaps in the protocol field IDs that were filled in between
> the versions. If the fields are reordered during the re-encoding then the
> bytes will not match the original stream that was signed and the token
> verification will fail.
> The original token identifier bytes received via RPC need to be used by the
> verification process, not the bytes generated by re-encoding the identifier.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
