[
https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259311#comment-15259311
]
Xiaoyu Yao commented on HDFS-10324:
-----------------------------------
Thanks [~andrew.wang] and [~jojochuang]. I agree with you analysis that we
probably don't need a provisionTrash API separately. I mean to have an overload
version of HdfsAdmin#createEncryptionZone with a provisionTrash parameter and
switch crypto CLI to call the new API. This way, we can deprecate the existing
API that does not create .Trash with permissions in the next few releases. Give
this will be an Admin wrapper API over DFS API with opt-out parameter, I think
it is an acceptable solution to save future document/support cost. What do you
think?
> 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
>
>
> 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)
