Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <28259951.1199470774071.JavaMail.jira@brutus>
Date: Fri, 4 Jan 2008 10:19:34 -0800 (PST)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-2514) Trash and permissions don't mix
In-Reply-To: <5178042.1199324374280.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Doug Cutting commented on HADOOP-2514:
--------------------------------------

> Do you really want to treat home directories as special?

Thinking more, we already hardwire home directories to "/user/<username>".  Folks cannot reconfigure that.  So it is safe for the trash feature to rely on this and put each user's trash in /user/<username>/.trash.  The trash location should thus no longer be configurable.

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

Note that, for back-compatibility, the dumper thread should still dump any global /trash.

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


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