Date: Mon, 5 Jun 1995 01:18:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org Cc: davidg@root.com Subject: races in ufs_rename() Message-ID: <199506041518.BAA31044@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
ufs_rename() tries hard to avoid races and deadlocks. I think it fails to avoid serious races in 2 places: 1) After looking up the source and before reaching ufs_rename(). The parent directory of the source isn't locked (locking might cause deadlock), so the source directory entry may be moved or deleted. This need not be serious, but it can cause a panic in the `doingdirectory' case when the source is unlinked. IN_RENAME was supposed to stop the source directory entry from being moved and an extra link was supposed to stop it being deleted, but these tricks are done too late. 2) In the `doingdirectory && newparent' case, when ufs_checkpath() is called, all locks on the target directories are released (hanging on to them might cause deadlock), so the target directories may be moved or deleted. I tested this by adding a tsleep() to ufs_checkpath() before the call to VFS_VGET() and had no difficulty moving the target directory to a bad place (a subdirectory of the source) while ufs_checkpath() was sleeping. ufs_rename() should at least check that relookup() of the target produces the same inode like it does for the source. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506041518.BAA31044>