[ 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: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org