[
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 moves a file to the
trash. This is an issue when other users try to move files to that trash
because they may not have the permission to move to that trash if the trash
root is shared. -- in this case, snapshottable directories.
This only affects users 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. just remove the
.Trash directory when disallowing snapshot on a dir if it is empty?
was:
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 move to
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. just remove the
.Trash directory when disallowing snapshot on a dir if it is empty?
> Create trash dir when allowing snapshottable dir
> ------------------------------------------------
>
> Key: HDFS-15607
> URL: https://issues.apache.org/jira/browse/HDFS-15607
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Affects Versions: 3.4.0
> 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 moves a file to the
> trash. This is an issue when other users try to move files to that trash
> because they may not have the permission to move to that trash if the trash
> root is shared. -- in this case, snapshottable directories.
> This only affects users 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. just remove the
> .Trash directory when disallowing snapshot on a dir if it is empty?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
