[
https://issues.apache.org/jira/browse/HDFS-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Lamb updated HDFS-6386:
-------------------------------
Attachment: HDFS-6386.012.patch
Thanks for the review. I've attached .012 which (I think) addresses all of your
previous comments.
bq. We need to rebase the fs-encryption branch (and this patch) on trunk.
The xattr code has changed slightly, one example being where we log the edit
(FSN now, not FSDir).
Done.
FSNamesystem:
bq. listEZ needs to only return EZs where the user has permission to know about
the EZ path, else we're exposing the existence of the path
In an offline conversation, we agreed that listEZ would become an su-only
operation. A new Jira (HDFS-6546) will create a new method/CLI command that
will allow a non-SU to ask whether a path is part of an EZ and if so, which
one. This reminded me to add tests for the createEZ and deleteEZ ops under a
non-superuser, which I have done in the .012 patch.
bq. In createEncryptionZone, we need to catch the KP exception such that it's
logged in the retry cache.
Fixed.
bq. Using FSDirectory#getPathComponentsForReservedPaths doesn't look right,
can you check that it's not returning null? Doing some more tests with multiple
EZs would be good, I noticed your listEZ test doesn't check the size of the
returned listing which might be masking an error here.
We agreed that it's ok to call getPathComponentsForReservedPaths is oik. I've
fixed the tests.
bq. KeyProvider should be a single word in javadoc
ok
FSDirectory:
bq. I think the exception thrown from unprotectedSetXAttr contains the
"system.xxx" xattr name. Maybe we should throw a fresh new exception rather
than showing this to the user. Could also test for this explicitly rather than
rethrowing an exception, since that's more expensive.
This check was being made further up anyway so I removed all this catch/rethrow
stuff.
bq. Do we care about repeating IVs? I'm not a cryptographer, but a Google
search turns up concerns for "stream cipher initialization vector birthday
paradox".
A new Jira (HDFS-6547) specifies that we will create a persistent counter and
build new IVs off of that.
KeyAndIv
Need interface annotations
Done.
> HDFS Encryption Zones
> ---------------------
>
> Key: HDFS-6386
> URL: https://issues.apache.org/jira/browse/HDFS-6386
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode, security
> Reporter: Alejandro Abdelnur
> Assignee: Charles Lamb
> Fix For: fs-encryption (HADOOP-10150 and HDFS-6134)
>
> Attachments: HDFS-6386.012.patch, HDFS-6386.4.patch,
> HDFS-6386.5.patch, HDFS-6386.6.patch, HDFS-6386.8.patch
>
>
> Define the required security xAttributes for directories and files within an
> encryption zone and how they propagate to children. Implement the logic to
> create/delete encryption zones.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
