From a92c6b24c0e92607661a16295f4b04cde08c9230 Mon Sep 17 00:00:00 2001 From: Robert Watson Date: Sat, 27 Feb 2021 16:22:26 +0000 Subject: [PATCH] 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. --- sys/security/mac/mac_vfs.c | 15 ++++++++++++--- 1 file 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); }