hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjay Radia (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-2514) Trash and permissions don't mix
Date Thu, 03 Jan 2008 21:37:34 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555682#action_12555682
] 

Sanjay Radia commented on HADOOP-2514:
--------------------------------------

Trash and permissions

Need to rethink trash - our initial thoughts were that all we needed was to add per-user trash-bins.
But it is more than that.

Areas to consider
 1. Per user trash
 - how do they get created. 
       * Can pre-create when home dir is created, but do need to handle case where a user,
that does not have private trash,  issues a delete file operation.

 2. Preserve the full parent path 
 - this may be hard to support in face of permissions and ownership especially because the
rm/mv is being     
   done on the client side
- Multiple deletes on the same path 
         * Perhaps each delete moves to a the per-user trash
- The mac's trash model where the parent path is not preserved may a better approach.

3. Asymmetry: moving to trash is  done on client side while the deletion of the trash is done
on the
    server side.
 - note that the checking of permissions for delete directory (recursively)  and move directory
are
    slightly different.
    * Both require Write perm on parent
    * Delete directory recursively requires that one has write permissions on ALL subdirectories.
- Due to the asymmetry, one could trick the system into deleting a subtree where one has Write
permissions only on the parent dir but not the subtree.
- Possible solution:   treat move to trash slightly differently since the system does treat
trash specially by automatically deleting things in the trash.

4. Client and server side config of trash location
Current system allows the client side and server side have independent configuration of the
location of  trash.
- with per-user trash this may need to be rethought.
- What was the original motivation of  this flexibility? Was it to allow a user to set his
trash to a place that is not GC'ed by the system?

	


> 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.


Mime
View raw message