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
This commit is contained in:
David Greenman 1995-05-15 07:31:09 +00:00
parent 64cecefe43
commit 9b5bb13bf8
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=8529

View File

@ -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 @@ ufs_rename(ap)
* 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 @@ ufs_rename(ap)
if (VOP_LOCK(fvp) == 0) {
ip->i_nlink--;
ip->i_flag |= IN_CHANGE;
ip->i_flag &= ~IN_RENAME;
vput(fvp);
} else
vrele(fvp);