xfs
[Top] [All Lists]

Re: Interesting XFS Behavior

To: Ethan Benson <erbenson@xxxxxxxxxx>
Subject: Re: Interesting XFS Behavior
From: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 8 Nov 2001 19:17:42 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20011107005250.V887@xxxxxxxxxxxxxxx>; from erbenson@xxxxxxxxxx on Wed, Nov 07, 2001 at 12:52:50AM -0900
References: <20011105225039.A599@xxxxxxxxxxxxxxxxxx> <1005058628.15251.15.camel@xxxxxxxxxxxxxxxxxxxx> <01110610360706.01823@office3> <20011107005250.V887@xxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
I don't think this is really an XFS issue but..

On Wed, Nov 07, 2001 at 12:52:50AM -0900, Ethan Benson wrote:
> On Tue, Nov 06, 2001 at 10:36:07AM -0500, Jeff Breitner wrote:
> > However, what's interesting is that after the user attempts this, the null 
> > file ".donotdelete" disappears.  Where does it go?  And even though it's 
> > gone, further attempts at removal are still met with "permission denied".
> > As user root, the file can't be listed nor deleted by name -- it just 
> > vanishes although something thinks it is there because only root can kill 
> > the 
> > directory containing the null file.
> > 
> > This is the behavior on my Irix 6.2 box as well (a feather in the cap of 
> > consistency).
> > 
> > Any ideas what's going on?  
> 
> perhaps you don't have write permission to the parent directory?  a
> directory like a file can only be removed if you have permission to
> the directory that contains it.  

Oh, ok, now I understand what Jeff was trying to do.
So there is no file which has vanished and yet still there -
it _has_ been deleted. It's just that he couldn't delete the containing
directory.

Yeah, AFAIK, you can't delete a directory entry from a directory when you
don't have write and exec permission in that directory.

Looking at linux/fs/namei.c, it seems that the function "may_delete",
does the testing for this.  It has the comment:
/*
 *      Check whether we can remove a link victim from directory dir, check
 *  whether the type of victim is right.
 *  1. We can't do it if dir is read-only (done in permission())
 *  2. We should have write and exec permissions on dir
 *  3. We can't remove anything from append-only dir
 *  4. We can't do anything with immutable dir (done in permission())
 *  5. If the sticky bit on dir is set we should either
 *      a. be owner of dir, or
 *      b. be owner of victim, or
 *      c. have CAP_FOWNER capability
 *  6. If the victim is append-only or immutable we can't do antyhing with
 *     links pointing to it.
 *  7. If we were asked to remove a directory and victim isn't one - ENOTDIR.
 *  8. If we were asked to remove a non-directory and victim isn't one - 
EISDIR. 
 *  9. We can't remove a root or mountpoint.
 */
static inline int may_delete(struct inode *dir,struct dentry *victim, int isdir)

--Tim


<Prev in Thread] Current Thread [Next in Thread>