Add a comment on why the call to mac_vnode_relabel() might be in the wrong

place -- in the VOP rather than vn_setexttr() -- and that it is for historic
reasons.  We might wish to relocate it in due course, but this way at least
we document the asymmetry.

1 files changed, 12 insertions, 3 deletions

diff --git a/sys/security/mac/mac_vfs.c b/sys/security/mac/mac_vfs.c
index 323d693387bb..3d2185fbc3c6 100644
--- a/sys/security/mac/mac_vfs.c
+++ b/sys/security/mac/mac_vfs.c
@@ -1021,6 +1021,10 @@ vop_stdsetlabel_ea(struct vop_setlabel_args *ap)
 	if (error)
 		return (error);
 
+	/*
+	 * XXXRW: See the comment below in vn_setlabel() as to why this might
+	 * be the wrong place to call mac_vnode_relabel().
+	 */
 	mac_vnode_relabel(ap->a_cred, vp, intlabel);
 
 	return (0);
@@ -1045,9 +1049,6 @@ vn_setlabel(struct vnode *vp, struct label *intlabel, struct ucred *cred)
 	 * Multi-phase commit.  First check the policies to confirm the
 	 * change is OK.  Then commit via the filesystem.  Finally, update
 	 * the actual vnode label.
-	 *
-	 * Question: maybe the filesystem should update the vnode at the end
-	 * as part of VOP_SETLABEL()?
 	 */
 	error = mac_vnode_check_relabel(cred, vp, intlabel);
 	if (error)
@@ -1068,6 +1069,14 @@ vn_setlabel(struct vnode *vp, struct label *intlabel, struct ucred *cred)
 	if (error)
 		return (error);
 
+	/*
+	 * It would be more symmetric if mac_vnode_relabel() was called here
+	 * rather than in VOP_SETLABEL(), but we don't for historical reasons.
+	 * We should think about moving it so that the filesystem is
+	 * responsible only for persistence in VOP_SETLABEL(), not the vnode
+	 * label update itself.
+	 */
+
 	return (0);
 }