[
https://issues.apache.org/jira/browse/HDFS-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148375#comment-16148375
]
Xiao Chen commented on HDFS-12359:
----------------------------------
Thanks for the review Wei-Chiu, added a few specific checks in patch 2.
Existing reencryption tests should cover this on a higher level.
bq. getCurrentKeyVersion would never return null.
A little confused by this comment:
# {{getCurrentKeyVersion}} could return null, if edek's
{{getCurrentKeyVersion}} is null. Even if in KMS we check it, it feels to me
safeguarding against nullity here does more good than harm.
# {{FSDirEncryptionZoneOp.getKeyNameForZone}} could also return null, since it
calls to:
{code:title=EncryptionZoneManager#getKeyName}
String getKeyName(final INodesInPath iip) {
assert dir.hasReadLock();
EncryptionZoneInt ezi = getEncryptionZoneForPath(iip);
if (ezi == null) {
return null;
}
return ezi.getKeyName();
}
{code}
> Re-encryption should operate with minimum KMS ACL requirements.
> ---------------------------------------------------------------
>
> Key: HDFS-12359
> URL: https://issues.apache.org/jira/browse/HDFS-12359
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: encryption
> Affects Versions: 3.0.0-beta1
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HDFS-12359.01.patch, HDFS-12359.02.patch
>
>
> This was caught from KMS acl testing.
> HDFS-10899 gets the current key versions from KMS directly, which requires
> {{READ}} acls.
> It also calls invalidateCache, which requires {{MANAGEMENT}} acls.
> We should fix re-encryption to not require additional ACLs than original
> encryption.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
