[
https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256505#comment-15256505
]
Xiaoyu Yao commented on HDFS-10324:
-----------------------------------
Thanks [~jojochuang] for updating the patch. Here are a few comments:
1. Can we assume 1777 for the .Trash directory for an encryption zone without
an additional configuration key fs.trash.encrypted.permission?
I don't see a clear use case that requires customization of the .Trash
permission.
2. How to we handle upgrade?
For newly created zone, .Trash will always be implicitly added without
additional parameter as patch 002 does.
For zone without .Trash (e.g., zone upgraded from previous version or .Trash
got deleted by accident) or correct .Trash permission (e.g., permission
modified by accident), maybe we can add a new crypto admin command "hdfs crypto
-provisiontrash" that will fix them up. 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
>
>
> 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)
