[ 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