From Bruce Evans:

I ran into another manifestation of the problem reported in PR 211 and
fixed it. Try this:

as non-root:
	cd /tmp; mkdir x y x/z
as root:
	chown root /tmp/x/z
as non-root:
	cd /tmp/x; mv z ../y		# EACCES as expected
as root:
	cd /tmp/x; mv z ../y		# EINVAL NOT as expected

This is because ufs_rename() sets IN_RENAME and fails to clear it.

Reviewed by:	davidg
Submitted by:	bde

1 files changed, 3 insertions, 2 deletions

diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c
index ae28273499ff..b5fef5da1799 100644
--- a/sys/ufs/ufs/ufs_vnops.c
+++ b/sys/ufs/ufs/ufs_vnops.c
@@ -36,7 +36,7 @@
  * SUCH DAMAGE.
  *
  *	@(#)ufs_vnops.c	8.10 (Berkeley) 4/1/94
- * $Id: ufs_vnops.c,v 1.21 1995/04/24 05:13:17 dyson Exp $
+ * $Id: ufs_vnops.c,v 1.22 1995/04/25 03:32:37 dyson Exp $
  */
 
 #include <sys/param.h>
@@ -1043,7 +1043,7 @@ abortit:
 	 * either case there is no further work to be done. If the source
 	 * is a directory then it cannot have been rmdir'ed; its link
 	 * count of three would cause a rmdir to fail with ENOTEMPTY.
-	 * The IRENAME flag ensures that it cannot be moved by another
+	 * The IN_RENAME flag ensures that it cannot be moved by another
 	 * rename.
 	 */
 	if (xp != ip) {
@@ -1112,6 +1112,7 @@ out:
 	if (VOP_LOCK(fvp) == 0) {
 		ip->i_nlink--;
 		ip->i_flag |= IN_CHANGE;
+		ip->i_flag &= ~IN_RENAME;
 		vput(fvp);
 	} else
 		vrele(fvp);