[jira] [Commented] (MAPREDUCE-3943) RM-NM secret-keys should be randomly generated and rolled every so often

["Daryn Sharp (JIRA)" <ji...@apache.org>]

    [ 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