[
https://issues.apache.org/jira/browse/HDFS-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012322#comment-14012322
]
Charles Lamb commented on HDFS-6387:
------------------------------------
Is there any reason why the createEncryptionZone operation shouldn't just
piggyback on the existing mkdirs protocol (MkdirsRequestProto)? The semantics
of the operation are essentially a mkdir with an optional key-id.
I assume that createEncryptionZone will be a new public method on FileSystem. I
also assume that the CLI implementation will go through that API.
For the CLI, we can either add a new command ("-createEncryptionZone" or
something like that), or add an option to mkdir (-mkdir [-ez <key-id>]). Same
question for -deleteEncryptionZone (or whatever we call it).
Which hdfs -dfs command will be used to tell the user that a file/directory is
part of an encryption zone? -ls, -stat, -getattr? -getfattr does not presently
return fsattrs from the system.* namespace, and it still wouldn't, but it could
be used to indicate membership in an EZ. Should the information that is
displayed to the user show the key-id/key-version? Probably only the admin
would ever be shown the key-id/key-version. Would a regular old user (who had
access to the EZ directory) be shown that it is indeed part of an EZ or would
the existence of the EZ only ever be made known to the HDFS admin?
> HDFS CLI admin tool for creating & deleting an encryption zone
> --------------------------------------------------------------
>
> Key: HDFS-6387
> URL: https://issues.apache.org/jira/browse/HDFS-6387
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode, security
> Reporter: Alejandro Abdelnur
> Assignee: Charles Lamb
>
> CLI admin tool to create/delete an encryption zone in HDFS.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
