Date: Mon, 08 Oct 2018 01:07:16 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 232021] zfs cannot mount 'dataset': Insufficient privileges Message-ID: <bug-232021-227-8jrPP64Vgo@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-232021-227@https.bugs.freebsd.org/bugzilla/> References: <bug-232021-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232021 --- Comment #12 from Allan Jude <allanjude@FreeBSD.org> --- After investigating further, I am a bit torn on this one. Rules that apply to mounting: if vfs.usermount =3D=3D 1, user must own the directory they are attempting = to mount to https://svnweb.freebsd.org/base/head/sys/kern/vfs_mount.c?view=3Dmarkup#l855 Rules that apply to unmounting: if vfs.usermount =3D=3D 1, user must be the one who mounted the filesystem UNLESS the filesystem has the VFCF_DELEGADMIN flag (which ZFS does), in whi= ch case the 'who did the mounting' check is bypassed.=20 https://svnweb.freebsd.org/base/head/sys/kern/vfs_subr.c?view=3Dmarkup#l718 So, ZFS has an exception to the vfs.usermount rule for unmounting. The kern= el allows ZFS to implement its own checks (zfs allow mount) to determine if the umount operation should succeed. This feels oddly asymmetrical to me, although I see the additional security considerations for mounting, vs umounting. Making the vfs.usermount 'who did the mounting' check apply feels like a regression against the administrators expressed intent with 'zfs allow moun= t' on the target filesystem. So it may be the case that we just need to document this as the intended behaviour. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232021-227-8jrPP64Vgo>