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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232021 --- 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 == 1, user must own the directory they are attempting to mount to https://svnweb.freebsd.org/base/head/sys/kern/vfs_mount.c?view=markup#l855 Rules that apply to unmounting: if vfs.usermount == 1, user must be the one who mounted the filesystem UNLESS the filesystem has the VFCF_DELEGADMIN flag (which ZFS does), in which case the 'who did the mounting' check is bypassed. https://svnweb.freebsd.org/base/head/sys/kern/vfs_subr.c?view=markup#l718 So, ZFS has an exception to the vfs.usermount rule for unmounting. The kernel 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 mount' on the target filesystem. So it may be the case that we just need to document this as the intended behaviour. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232021-227-8jrPP64Vgo>