[
https://issues.apache.org/jira/browse/YARN-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752573#comment-13752573
]
Jason Lowe commented on YARN-707:
---------------------------------
Thanks for the review, Daryn.
bq. Technically you should be bumping the token ident's version number and
using that to determine if the app submitter is in the ident. Otherwise,
decoding of prior tokens will attempt to read the missing app submitter from
the next serialized object and eventually fail spectacularly.
Talked with [~daryn] offline, there isn't a version ID in the token to bump.
Will file a followup JIRA. I do not know how to avoid the issue with the
deserialization of the old format given there is no way to detect it.
bq. Using checks on UserGroupInformation.isSecurityEnabled() here and elsewhere
will cause future incompatibility to require tokens w/o security which is the
direction yarn has been moving in. It would be better to check if the secret
manager is not null.
Filed YARN-1108 to track the change where we always require client AM tokens.
I'd rather not make that change as part of this JIRA. Given that there is
always a client-to-AM secret manager even when security is not enabled, I'd
rather defer that change to YARN-1108.
bq. It's just logging if it cannot create a token? This shouldn't happen, but
if/when it does it's going to lead to more difficult after the fact errors in
the client. It's unfortunate you cannot throw the checked exception
IOException, so I think you need to change the method signature or throw
whatever you can, like a YarnException, to fail the request.
I had it log a message since that's what the existing code already does below
in the same method when it cannot determine the current user. There are
already other, legitimate scenarios in which the client will not receive an AM
token (i.e.: it does not have VIEW_JOB access), and the client will not
necessarily want to connect to the AM even if it does have access. It could be
getting the report just to track the app at a high level, and I thought it was
a bit extreme to fail the entire request just because a small part of it that
may not even be used by the client cannot be generated. If others feel this
should be fatal to the request, I can be convinced to change it.
bq. App attempting storing/restoring appears asymmetric. Storing saves off the
whole credentials in the attempt, whereas restoring appears to just pluck out
the amrm token and the new persisted secret?
The Credentials are just a bag to hold the token and key, so it fills out an
empty one with those two items and plucks those two back out when it gets the
bag of stuff back. The Credentials is just a transport mechanism in the code.
I agree it's a bit odd that the RMAppAttemptImpl does some of this work and
RMStateStore does the other, but I'm just preserving the existing architecture.
Changing that is outside the scope of this JIRA, IMHO.
bq. Methods using the term "Token", ex. recoverAppAttemptTokens and
getTokensFromAppAttempt are misleading since it's "Credentials"
Given that it used to be just tokens before this change, I'll change "Tokens"
to "Credentials" in methods to better reflect what was going on.
bq. AM_CLIENT_TOKEN_MASTER_KEY_NAME is better defined in RMAppAttempt, rather
than in the RMStateStore.
I put it in RMStateStore since that's where AM_RM_TOKEN_SERVICE already existed
and it's a similar concept -- naming something that needs to be stored. I'll
move this to RMAppAttemptImpl if others feel that's a better place for it.
> Add user info in the YARN ClientToken
> -------------------------------------
>
> Key: YARN-707
> URL: https://issues.apache.org/jira/browse/YARN-707
> Project: Hadoop YARN
> Issue Type: Improvement
> Reporter: Bikas Saha
> Assignee: Jason Lowe
> Priority: Blocker
> Fix For: 3.0.0, 2.1.1-beta
>
> Attachments: YARN-707-20130822.txt, YARN-707-20130827.txt
>
>
> If user info is present in the client token then it can be used to do limited
> authz in the AM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
