Directory rename semantics.

Edward Tomasz Napierala trasz at FreeBSD.org
Mon Oct 27 19:51:05 UTC 2008


Let's say we have two directories, "A/" and "B/".  We also have a
file, "A/F".  To remove that file, we need write access to "A/".
To move that file to "B/", we need write access to both "A/" and
"B/".  Now, assume we have a directory, "A/D".  To remove that
directory, we need write access to "A/".  To move that directory
to "B/", we need write access to "A/", "B/", _and "A/D"_.

I'd like to remove the last check (requirement to have write access
to a directory we want to move somewhere else).  Reason for this
is that it doesn't seem very logical, and many systems - including
SunOS, and our ZFS - behave differently.  In other words, we have
different semantics on UFS and ZFS.

This change seems to be ok from the standards point of view - SUSv3
says the operating system MAY perform this check.

Index: sys/ufs/ufs/ufs_vnops.c
===================================================================
--- sys/ufs/ufs/ufs_vnops.c	(revision 182813)
+++ sys/ufs/ufs/ufs_vnops.c	(working copy)
@@ -1122,19 +1122,14 @@
 	 * If ".." must be changed (ie the directory gets a new
 	 * parent) then the source directory must not be in the
 	 * directory hierarchy above the target, as this would
-	 * orphan everything below the source directory. Also
-	 * the user must have write permission in the source so
-	 * as to be able to change "..". We must repeat the call
-	 * to namei, as the parent directory is unlocked by the
-	 * call to checkpath().
+	 * orphan everything below the source directory.  We must
+	 * repeat the call to namei, as the parent directory
+	 * is unlocked by the call to checkpath().
 	 */
-	error = VOP_ACCESS(fvp, VWRITE, tcnp->cn_cred, tcnp->cn_thread);
 	VOP_UNLOCK(fvp, 0);
 	if (oldparent != dp->i_number)
 		newparent = dp->i_number;
 	if (doingdirectory && newparent) {
-		if (error)	/* write access check above */
-			goto bad;
 		if (xp != NULL)
 			vput(tvp);
 		error = ufs_checkpath(ip, dp, tcnp->cn_cred);



More information about the freebsd-arch mailing list