[
https://issues.apache.org/jira/browse/HADOOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556122#action_12556122
]
Sanjay Radia commented on HADOOP-2514:
--------------------------------------
>> 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).
>I'd rather avoid having a global /trash directory altogether. Shouldn't we try
>to create the user's trash, and throw an exception when that fails? It
>shouldn't fail often.
In a properly configured system, creating a user's home dir will always fail
(unless the user is a super user), since /home is not world writable. However
creating a .trash in /users/<userName> will succeed since it is being done by
the same user.
So if the home directory does not exist, I am proposing that deletes move to a
common trash area.
(I don't like the idea of automagically creating /users/<username> for a
missing homedir.)
Also note with the trashbin in /user/<userName>/.trash, instead of
/trash/<userName> the trashbin compacter will have
to look in multiple home dirs instead of merely in /trash.
Because of this most of the folks in our whiteboard discussions preferred to
have a /trash/<user>.
>> The user should have been notified when he did the original delete/rename
>> that he is not allowed to delete/rename.
>Yes, I agree. So the trash code should check permissions both when moving
>something to the trash and when dumping the trash. >Things could still get
>stuck in a user's trash directory if they're chmodded after they're put in the
>trash, but that's rare enough to be >acceptable.
Unfortunately the client side code may find it expensive to do a rpc
per-subtree-entry when deleting a large subtree.
Hence this is best done on NN side (which makes the NN aware of the special
case for trash (ugly)).
BTW the trashbin compacter can never fail to delete things since he is super
user.
The trashbin compacter is running as root.
Are you suggesting a per-user trashbin compacter running as the user?
... looks like we are converging on our discussions :-)
> 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.
