[
https://issues.apache.org/jira/browse/MAPREDUCE-3943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438282#comment-13438282
]
Daryn Sharp commented on MAPREDUCE-3943:
----------------------------------------
*ContainerManagerImpl*
# {{authorizeRequest}} assuming one and only one token is a landmine. Should
either throw if more than one, or use the token selector to get the intended
one.
# {{isValidStartContainerRequest(tokenId)}} is invoked before the null check
for {{tokenId}}
# Container starts verify the token hasn't already been used. Should status &
stop maybe verify it _has_ been used, ie. started?
# Should "Attempt to use an old secret key ..." but something more like
"Attempt to relaunch a container"?
*ResourceTrackerService*
# Should refs to {{BaseContainerTokenSecretManager}} be
{{RMContainerTokenSecretManager}}?
*NMTokenSecretManager*
# {{retrievePassword}} has a fallback to the current master key when it knows
the token is invalid. Why not throw InvalidToken exception?
# {{startContainerSuccessful}} is assuming one and only one token. Perhaps
pass it the token validated in {{authorizeRequest}}?
# _Important_: {{appFinished}} "forgets" containers already launched, thus
allowing tokens to relaunch containers for 48 hours. The token essentially
needs to be cancelled after use which probably means remembering them until
hard expiration.
*General questions*
In general, it seems like so many objects shouldn't need to hold a reference to
the secret managers. Isn't there a context that can hold a ref?
Using events to sync the secret keys between the {{RMContainerSecretManager}}
and {{ResourceTrackerService}} (which actually has a ref to the secret
manager!) is rather complex. It was difficult to ensure major race conditions
don't exist. Would using the read-write lock, instead of sync keyword, in the
secret manager for key access have made it simpler?
> RM-NM secret-keys should be randomly generated and rolled every so often
> ------------------------------------------------------------------------
>
> Key: MAPREDUCE-3943
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3943
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: mrv2, security
> Affects Versions: 0.23.0
> Reporter: Vinod Kumar Vavilapalli
> Assignee: Vinod Kumar Vavilapalli
> Priority: Critical
> Attachments: MAPREDUCE-3943-20120416.txt, MR3943_branch-23.txt,
> MR3943_branch-23.txt, MR3943_trunk.txt, MR3943_trunk.txt, MR3943.txt,
> MR3943.txt
>
>
> - RM should generate the master-key randomly
> - The master-key should roll every so often
> - NM should remember old expired keys so that already doled out
> container-requests can be satisfied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
