[
https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259231#comment-15259231
]
Andrew Wang commented on HDFS-10324:
------------------------------------
Thanks for the discussion all, and Wei-Chiu for the patch.
HdfsAdmin is a public API, so I don't think we should modify createZone there
to also provisionTrash. It'd mean we have no way of creating a zone without a
Trash directory (the old behavior) and also gets into my earlier concerns about
atomicity.
We can revisit this later if we find we need Java API access to provisionTrash,
but that should be rare since you can just do it with mkdir and chmod.
Review comments:
* Shall we error if provisionTrash isn't called on an EZ root? That more
clearly reflects that the Trash directory is an EZ-level construct.
* If a Trash directory already exists, it might already be set up properly, so
it seems harsh to tell the user to rename it. Instead, how about e.g. "Will not
provision new trash directory for encryption zone /ez/, path already exists."
* We can get fancy with the above, and print additional warnings if .Trash is a
file, or the permissions are set wrong (and what the right permissions are).
* In the md file, let's not add a step that will return an error return code to
the example usage. Instead, we should add some help text to the "createZone"
command, and update the md file too.
* The provisionTrash help description also needs to be added to the md file.
* We can talk about the pre-2.8.0 behavior, sticky bit, and provisionTrash in
the "Rename and Trash considerations" section.
* One of the unit tests should verify that the sticky bit is set on a
provisioned Trash directory.
> 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)
