[
https://issues.apache.org/jira/browse/HADOOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556773#action_12556773
]
Sanjay Radia commented on HADOOP-2514:
--------------------------------------
Option 2: A little bit more than the minimal described in my previous comment:
add per-user trash
===========================================================================
a. each home directory has a .trash (created on fly when needed) with perms of
u: rwx, g:none w:none
(BTW each home directory has permissions of u: rwx, g:rx.w:x)
b. Objects moved to /trash do not preserve the parent path. (change from 0.15 -
we cannot preserve the parent perms from client side.)
i.e. if you issue: "rm /foo/dir_bar" then dir_bar is moved to the trash -
ithe subtree under dir_bar is preserved but /foo is NOT preserved.
c. the rm shell command moves things to the user's trash (creating it if it
can).
If the user does not have a home directory then one is created if possible
(usually not because usually only superuser has
write permissions on /user.)
If trash cannot be created, then the file is merely deleted (i.e file is NOT
moved to common /trash)
Only the shell command provides the builtin alias to mv - the
FileSystem.delete(path) does NOT move files to trash.
d. The thread compacter runs as super user and deletes stuff from each user's
.trash
No permission checking is done by the thread compacter.
What is the security violation of the above?
=================================
* Any user can trick the trash compacter to delete objects that they have
permission to move but not to delete.
Ie issuing a "rm dir_foo", or "mv dir_foo /user/u/.trash" or
rename(dir_foo, /user/u/.trash/dirfoo) will result in the dir_foo being deleted
by
the trash compacter - there will be no checking of permission in the
subtree of dir_foo.
Is the above acceptable for 0.16?
> 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.
