[
https://issues.apache.org/jira/browse/HDFS-15607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDFS-15607:
------------------------------
Description:
In {{TrashPolicyDefault}}, the {{.Trash}} directory will be created with
permission 700 without sticky bits by the first user that attempts to move a
file to the trash. This causes issue when a second user tries to move a file to
that trash because the second user might not have the permission to the trash.
Only affects the user when trash is enabled inside snapshottable directories,
and when the user doesn't have admin permissions.
Solution: Create a .Trash directory with 777 permission and sticky bits enabled
(similar solution as HDFS-10324).
Also need to deal with some corner cases:
1. even when the snapshottable directory trash root config is not enabled,
create the {{.Trash}} directory anyway?
2. When immediately disallowing trash, it shouldn't fail. i.e. remove the empty
.Trash directory when disallowing snapshot on a dir
was:
In {{TrashPolicyDefault}}, the {{.Trash}} directory will be created with
permission 700 without sticky bits of the first user that attempts to move a
file to the trash. This causes issue when a second user tries to move a file to
that trash cause the user might not have the permission to do so.
Rationale is similar to HDFS-10324 except that one was for the encryption zone.
Only affects the user when trash is enabled inside snapshottable directories,
and when the user doesn't have admin permissions.
Solution: Create a .Trash directory with 777 permission and sticky bits enabled
(same as HDFS-10324).
Also, need to deal with some corner cases:
1. When the snapshottable directory trash root config is not enabled
2. When immediately disallowing trash, it shouldn't fail. i.e. remove the empty
.Trash directory when disallowing snapshot on a dir
> Trash directory should be created in advance for snapshottable directory
> ------------------------------------------------------------------------
>
> Key: HDFS-15607
> URL: https://issues.apache.org/jira/browse/HDFS-15607
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
>
> In {{TrashPolicyDefault}}, the {{.Trash}} directory will be created with
> permission 700 without sticky bits by the first user that attempts to move a
> file to the trash. This causes issue when a second user tries to move a file
> to that trash because the second user might not have the permission to the
> trash.
> Only affects the user when trash is enabled inside snapshottable directories,
> and when the user doesn't have admin permissions.
> Solution: Create a .Trash directory with 777 permission and sticky bits
> enabled (similar solution as HDFS-10324).
> Also need to deal with some corner cases:
> 1. even when the snapshottable directory trash root config is not enabled,
> create the {{.Trash}} directory anyway?
> 2. When immediately disallowing trash, it shouldn't fail. i.e. remove the
> empty .Trash directory when disallowing snapshot on a dir
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
