[
https://issues.apache.org/jira/browse/HDFS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13653324#comment-13653324
]
Aaron T. Myers commented on HDFS-2856:
--------------------------------------
Thanks a lot for working on this issue, Chris. Two questions for you:
# In steps 5 and 6 of the proposed protocol, I think you may need to do an
's/block key/block access token/g'. As you have it currently, if the server
digest returned by the DN is based on the block key directly, the client will
not be able to recompute/verify the returned server digest, since the client
does not know the block key. However, the client does know the block access
token, and a properly authenticated DN will be able to recompute the block
access token based on the block key it shares with the NN.
# Did you consider at all scrapping our custom authentication protocol and
instead switching to using straight SASL MD5-DIGEST for the
DataTransferProtocol? This is roughly what I did to add support for encrypting
the DataTransferProtocol in HDFS-3637.
> Fix block protocol so that Datanodes don't require root or jsvc
> ---------------------------------------------------------------
>
> Key: HDFS-2856
> URL: https://issues.apache.org/jira/browse/HDFS-2856
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: datanode, security
> Reporter: Owen O'Malley
> Assignee: Chris Nauroth
> Priority: Blocker
> Attachments: Datanode-Security-Design.pdf,
> Datanode-Security-Design.pdf, Datanode-Security-Design.pdf
>
>
> Since we send the block tokens unencrypted to the datanode, we currently
> start the datanode as root using jsvc and get a secure (< 1024) port.
> If we have the datanode generate a nonce and send it on the connection and
> the sends an hmac of the nonce back instead of the block token it won't
> reveal any secrets. Thus, we wouldn't require a secure port and would not
> require root or jsvc.
--
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