[
https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15271156#comment-15271156
]
Xiaoyu Yao commented on HDFS-10324:
-----------------------------------
Thanks [~jojochuang] for updating the patch. The patch looks good to me
overall. I just have a few minor issues listed below:
1. TrashPolicyDefault#TRASH is a unused private and can be removed.
2. TrasnparentEncryption.md can we highlight only the root path of the
encryption zone is allowed.
{{| *path* | The path of the encryption zone. |}} => {{| *path* | The path to
the root of the encryption zone. |}}
3. TestRpcProgramNfs3.java
Unused import: import org.apache.hadoop.crypto.key.KeyProviderFactory;
4. CreateEncryptionZoneFlag.java
I see we use noFlag to fix the unit tests that call the deprecated
HdfsAdmin#createEncyrption API. Do you consider add this as a flag such as
NO_FLAG((shot)) 0x0) to CreateEncryptionZoneFlag so that 3rd party can easily
migrate existing code to the new API?
{code} protected final EnumSet< CreateEncryptionZoneFlag > noFlag =
EnumSet.noneOf(CreateEncryptionZoneFlag.class);
{code}
5. HDFSCommands.md, the new CLI option have a <path> argument without -path. Do
we want to to be consistent here using {{ -path <path>}} like the existing
{{hdfs crypto -createZone -keyName <keyName> -path <path>}}?
{code}
hdfs crypto -provisionTrash <path>
{code}
6. HdfsAdmin.java
For the new API HdfsAdmin#CreateEncryptionZone, Can you highlight the
difference in the javadoc? For example, "additional provision steps such as
Trash can be enabled with the new flags parameter."
HdfsAdmin#provisionEZTrash can we change trashPermission to be class static?
7. CryptoAdmin.java
Same as 5. Suggest adding a -path before <path> to be consistent.
Suggest change "The path to the encryption zone." to "The path to the root of
the encryption zone" in the code below.
{code}
listing.addRow("<path>", "The path to the encryption zone. ");
{code}
> Trash directory in an encryption zone should be pre-created with sticky bit
> ---------------------------------------------------------------------------
>
> Key: HDFS-10324
> URL: https://issues.apache.org/jira/browse/HDFS-10324
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: encryption
> Affects Versions: 2.8.0
> Environment: CDH5.7.0
> Reporter: Wei-Chiu Chuang
> Assignee: Wei-Chiu Chuang
> Attachments: HDFS-10324.001.patch, HDFS-10324.002.patch,
> HDFS-10324.003.patch, HDFS-10324.004.patch, HDFS-10324.005.patch,
> HDFS-10324.006.patch
>
>
> We encountered a bug in HDFS-8831:
> After HDFS-8831, a deleted file in an encryption zone is moved to a .Trash
> subdirectory within the encryption zone.
> However, if this .Trash subdirectory is not created beforehand, it will be
> created and owned by the first user who deleted a file, with permission
> drwx------. This creates a serious bug because any other non-privileged user
> will not be able to delete any files within the encryption zone, because they
> do not have the permission to move directories to the trash directory.
> We should fix this bug, by pre-creating the .Trash directory with sticky bit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
