[
https://issues.apache.org/jira/browse/HDFS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524793#comment-16524793
]
Erik Krogen edited comment on HDFS-13617 at 6/27/18 9:15 AM:
-------------------------------------------------------------
Hey [~vagarychen], I just tried to apply this on trunk and the patch failed to
apply. Can you try rebasing again?
Some initial thoughts:
* {{PBHelperClient}} L357 is checking if {{builder}} has a handshake secret; it
should be checking {{tok}}
* For {{DFS_QOP_WRAP_HMAC_ALGORITHM_DEFAULT}}, it looks like other similar
usages hard-code this. Does this need to be configurable? Is it required to
match the HMAC algorithm for the {{BlockTokenSecretManager}}, or can you
mix-and-match a {{SecretKey}} and {{Mac}} with different algorithms? If they
need to match, we should use a shared constant.
* Is {{IOException}} really the right exception to throw for the two
misconfiguration cases within the {{NameNodeRpcServer}} constructor? I think a
{{Precondition}} or {{IllegalArgumentException}} or something would be more
suitable.
* The {{Mac}} instance needs to be {{ThreadLocal}}. It could also use a more
descriptive name.
* Looking at the patch makes me feel that we need to reduce the attack surface
for replay attacks. For example, instead of just generating a secret of the
QOP, can we generate a secret of the QOP + clientUserName (which can't be faked
due to Kerberos auth)? I think ideally it would contain some combination of the
QOP, client user name, client IP, and block ID.
Just for my reference, this patch *only* adds the NameNode side of things; the
client / DataNode handling is in HDFS-13699.
was (Author: xkrogen):
Hey [~vagarychen], I just tried to apply this on trunk and the patch failed to
apply. Can you try rebasing again?
Some initial thoughts:
* {{PBHelperClient}} L357 is checking if {{builder}} has a handshake secret; it
should be checking {{tok}}
* For {{DFS_QOP_WRAP_HMAC_ALGORITHM_DEFAULT}}, it looks like other similar
usages hard-code this. Does this need to be configurable?
* Is {{IOException}} really the right exception to throw for the two
misconfiguration cases within the {{NameNodeRpcServer}} constructor? I think a
{{Precondition}} or {{IllegalArgumentException}} or something would be more
suitable.
* The {{Mac}} instance needs to be {{ThreadLocal}}. It could also use a more
descriptive name.
* Looking at the patch makes me feel that we need to reduce the attack surface
for replay attacks. For example, instead of just generating a secret of the
QOP, can we generate a secret of the QOP + clientUserName (which can't be faked
due to Kerberos auth)? I think ideally it would contain some combination of the
QOP, client user name, client IP, and block ID.
Just for my reference, this patch *only* adds the NameNode side of things; the
client / DataNode handling is in HDFS-13699.
> Allow wrapping NN QOP into token in encrypted message
> -----------------------------------------------------
>
> Key: HDFS-13617
> URL: https://issues.apache.org/jira/browse/HDFS-13617
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Chen Liang
> Assignee: Chen Liang
> Priority: Major
> Attachments: HDFS-13617.001.patch, HDFS-13617.002.patch
>
>
> This Jira allows NN to configurably wrap the QOP it has established with the
> client into the token message sent back to the client. The QOP is sent back
> in encrypted message, using BlockAccessToken encryption key as the key.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
