Re: [9fans] mv vs cp

[Alexander Viro <viro@math.psu.edu>]

[I suggest taking the thread off-list - further details of rename() races
in *BSD may be interesting, but they are off-topic for 9fans]

On Mon, 8 Oct 2001, George Michaelson wrote:

> Are you saying that this problem demonstrably exploited the race condition
> between cp/mv and rename as implemented in FreeBSD?

	Yes.  ufs_rename() is racy and yes, that race is wide enough to be
exploitable.  BTDT.
 
> I really do mean the question as put:
> 
> when was the last time anybody saw a successful exploit of this race condition
> or an unstable filesystem they can show came from it, exploit or accident?
> 
> I have seen many problems with UFS/FFS, and Softupdates gave me the willeys
> but I have also not yet seen serious corruption of the on-disk state which
> lies directly with problems in the FS code itself. Side-effects of kernel
> crashes during meta-state updates, sure. But this sounds to me like FUD which
> in practice doesn't exist.

	process 1:  current directory in /tmp/a/a/a/a/a, does
rename("/tmp/b/b", "a");
	process 2:  current directory in /tmp/b/b/b/b/b, does
rename("/tmp/a/a", "b");

	Normal outcome: first process to do rename() succeeds, second - fails
with ELOOP.  With the right timing _both_ succeed, creating a loop and
detaching it from the rest of filesystem.

	Notice that use of relative pathnames is critical here - otherwise
lookup in the second rename() will block on the lock acquired by the first
one.  Code in /sys/ufs/ufs/ufs_vnops.c implicitly assumes that lookups
ending in descendants of directory will have to pass through that directory.
That assumption is obviously false - namei(9) can start in a descendant of
directory in question.

	And no, it's not too narrow - window includes quite a bit of disk
IO.  Figuring out details of turning that into full-blown attack (i.e.
what should be done to widen the window) are left as an exercise to anyone
who can RTFS - it's pretty straightforward.