[
https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254284#comment-15254284
]
Xiaoyu Yao commented on HDFS-10324:
-----------------------------------
Thanks [~jojochuang] for reporting the issue and posting the patch and
[~andrew.wang] for the comments.
Trash is mostly a client side feature. Mix it with createEncryptionZone API is
not an ideal solution.
[~jojochuang], have you try handle create of trash root in
{{TrashPolicyDefault#moveToTrash}} upon first deletion of file in the
encryption zone. The code below is just to illustrate the idea. It needs
additional tweak to work around the default UMASK enforced by
FileSystem.mkdir() to have the FsAction.All for g/o and sticky bit set
correctly. DistributedFileSystem#primitiveMkdir fits better here but is
currently not exposed to FileSystem interface.
{code}
private static final FsPermission ENCRYPTED_TRASH_ROOT_PERMISSION =
new FsPermission(FsAction.ALL, FsAction.ALL, FsAction.ALL, true);
...
Path trashRootParent = trashRoot.getParent();
if (!fs.exists(trashRootParent) &&
fs.getFileStatus(trashRootParent.getParent()).isEncrypted()) {
fs.mkdirs(trashRootParent, ENCRYPTED_TRASH_ROOT_PERMISSION);
}
{code}
[~andrew.wang]'s suggestion to handle .Trash permission for encryption zone via
{{hdfs crypto}} command looks fine but has a similar upgrade issue.
> 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
>
>
> 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)
