[
https://issues.apache.org/jira/browse/HADOOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555754#action_12555754
]
Sanjay Radia commented on HADOOP-2514:
--------------------------------------
>> need to handle case where a user, that does not have private trash, issues a
>> delete file operation.
>Can't we simply create one on demand in this case?
If the per-user trash is in a common /trash as in /trash/<userName> then one
cannot create the
trash-bin on the fly on the client side. A user does not have write permission
on /trash; only on /trash/<user>.
If trash is in /user/<userName>/.trash, then we can create it on demand, but
then the problem occurs
when the user deleting the file does not have a home directory.
(Because there is single trash compacter, it seems better to have all the
per-user trashbins be in /trash.;
but this is separable issue.)
So we can do the following: if the per-user trash-bin exists then move it there
otherwise move it
to /trash/common (or merely throw an exception).
> Trash and permissions don't mix
> -------------------------------
>
> Key: HADOOP-2514
> URL: https://issues.apache.org/jira/browse/HADOOP-2514
> Project: Hadoop
> Issue Type: New Feature
> Components: dfs
> Affects Versions: 0.16.0
> Reporter: Robert Chansler
> Fix For: 0.16.0
>
>
> Shell command "rm" is really "mv" to trash with the expectation that the
> server will at some point really delete the contents of trash. With the
> advent of permissions, a user can "mv" folders that the user cannot "rm". The
> present trash feature as implemented would allow the user to suborn the
> server into deleting a folder in violation of the permissions model.
> A related issue is that if anybody can mv a folder to the trash anybody else
> can mv that same folder from the trash. This may be contrary to the
> expectations of the user.
> What is a better model for trash?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.