bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rm -r sometimes produces errors under NFS


From: Vincent Lefevre
Subject: Re: rm -r sometimes produces errors under NFS
Date: Thu, 8 Mar 2007 12:35:49 +0100
User-agent: Mutt/1.5.14-vl-r16324 (2007-03-07)

On 2007-03-08 00:13:48 -0800, Paul Eggert wrote:
> Here's a more-diabolical example.  You invoke 'rm a/b/c', and a/b/c is
> read-only.  Some other process temporarily renames a/b to a/B between
> the time that 'rm' stats a/b/c and the time 'rm' invokes
> euidaccess("a/b/c", W_OK); the other process then renames a/B back to
> a/b after euidaccess is invoked.  In this case, euidaccess fails with
> ENOENT but the unpatched 'rm' will go ahead and remove a/b/c (even
> though a/b/c is read-only!) whereas the patched 'rm' will diagnose the
> problem and refuse to remove a/b/c.

I don't understand completely, but note that you can't avoid all
race conditions. For instance, you invoke 'rm a/b/c', a/b/c being
read-only, and where b is a symlink to some directory. Just after
the rm, some other process changes the symlink target, so that
a/b/c is an existing file, with writing permissions. When rm stats
this file, it sees that it can remove it without any confirmation.
Assume that just after the stat, the other process reverts the
symlink target. Then rm will remove the read-only file without
any confirmation.

The following example (which is *different*) shows that rm doesn't
see the target change:

Initial configuration:

lrwxrwxrwx 1 4 2007-03-08 12:17:03 dir -> dir1/
-r-------- 1 0 2007-03-08 12:15:59 dir1/foo
-rw-r--r-- 1 0 2007-03-08 12:15:59 dir2/foo

$ rm dir/foo
rm: remove write-protected regular empty file `dir/foo'?

Before answering, one changes the target:

lrwxrwxrwx 1 4 2007-03-08 12:18:43 dir -> dir2/
-r-------- 1 0 2007-03-08 12:15:59 dir1/foo
-rw-r--r-- 1 0 2007-03-08 12:15:59 dir2/foo

One answers 'yes':

rm: remove write-protected regular empty file `dir/foo'? y

And one can see that the removed file was not the protected one
(which was considered above):

lrwxrwxrwx 1 4 2007-03-08 12:18:43 dir -> dir2/
-r-------- 1 0 2007-03-08 12:15:59 dir1/foo

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]