hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-707) Add user info in the YARN ClientToken
Date Wed, 28 Aug 2013 16:58:53 GMT

    [ 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

Mime
View raw message