[
https://issues.apache.org/jira/browse/HDFS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697123#comment-13697123
]
Chris Nauroth commented on HDFS-2856:
-------------------------------------
{quote}
Will multiplexing help with this jira's use case?
{quote}
My comment referred to the fact that block-level operations, like readBlock and
writeBlock, require a unique authorization decision per block, using a
different block access token for each one. If multiple readBlock/writeBlock
calls were pipelined over a single connection, then we'd need to check
authorization on each one. If authorization for DataTransferProtocol is moving
fully to SASL, then this implies to me that we would need to renegotiate SASL
at the start of each block-level operation.
I don't see a way for multiplexing to help with this problem, because there
would still be the problem that we don't know what block the client requested
until we start inspecting the front of the message. I haven't followed the
RPCv9 changes closely though, so if I'm misunderstanding, please let me know.
Thanks, Daryn.
> 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
> 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
