xfs
[Top] [All Lists]

Re: Interesting XFS Behavior

To: linux-xfs@xxxxxxxxxxx
Subject: Re: Interesting XFS Behavior
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Wed, 7 Nov 2001 00:52:50 -0900
In-reply-to: <01110610360706.01823@office3>; from memptr@xxxxxxxxxxx on Tue, Nov 06, 2001 at 10:36:07AM -0500
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <20011105225039.A599@xxxxxxxxxxxxxxxxxx> <1005058628.15251.15.camel@xxxxxxxxxxxxxxxxxxxx> <01110610360706.01823@office3>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Nov 06, 2001 at 10:36:07AM -0500, Jeff Breitner wrote:
> 
> I have been goofing around trying to mimic the chattr -/+i features of ext2.  
> I figured out that I can keep directories from being deleted if I copy 
> /dev/null into a hidden file, say .donotdelete and then chmod 000 
> .donotdelete.

that won't work, its the directory permissions that control whether
you are allowed to delete a file, not the file's permissions.

rm (or maybe only GNU rm) does warn you by default if you tell it to
remove a file which you don't have write permission to, but if you
answer y is will still remove it.

> This keeps users from killing off the directory as they are greeted with a 
> "permission denied" if they try an rm -r <dirname> or rmdir.

i don't see how, unless the directory is sticky and owned by someone
other then the user.

adding support to XFS for chattr +i and +a should not be that
difficult, these attributes should be storable in an extended
attribute (root only and restricted by capabilities somehow).  then
just teach XFS about whatver syscall chattr is using.  

> 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.  of course root should not be affected
by that.  removing a non-empty directory results in `directory not
empty' not a permission denied.  

observe:

eb@socrates ~$ ls -ld foo
drwxr-xr-x    3 eb       eb           4096 Nov  7 00:50 foo
eb@socrates ~$ ls -lAR foo
foo:
total 8
drwxr-xr-x    2 root     root         4096 Nov  7 00:48 bar
drwxr-xr-x    2 root     root         4096 Nov  7 00:49 root

foo/bar:
total 0
-rw-r--r--    1 root     root            0 Nov  7 00:48 baz

foo/root:
total 0
eb@socrates ~$ rm -rf foo
rm: cannot unlink `foo/bar/baz': Permission denied
rm: cannot remove directory `foo/bar': Directory not empty
rm: cannot remove directory `foo': Directory not empty
eb@socrates ~$ ls -l foo/
total 4
drwxr-xr-x    2 root     root         4096 Nov  7 00:48 bar

whereas say:

eb@socrates ~$ ls -lAR /lost+found/
/lost+found/:
total 0
eb@socrates ~$ rm -rf /lost+found/
rm: cannot remove directory `/lost+found': Permission denied
eb@socrates ~$

hope that clears things up.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpDQfFfGLAhE.pgp
Description: PGP signature

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