Date: Mon, 3 Apr 2006 23:30:23 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: Re: RFC: Adding a ``user'' mount option Message-ID: <20060403232730.E76562@fledge.watson.org> In-Reply-To: <44316CAB.2040706@FreeBSD.org> References: <1144042356.824.16.camel@shumai.marcuscom.com> <20060403104309.Y76562@fledge.watson.org> <44316CAB.2040706@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: >> I would suggest that an extremely careful security audit of the userspace >> and kernel mount and unmount code is due -- especially things like the >> per-filesystem mount code (mount_nfs, etc). I'm not against the principle >> of this though. > > Agreed. I was hoping to make this solution secure, flexible, and easy to > use. Sure. And if you don't commit bug fixes to mount, we'll know you haven't tried looking very hard, because it seems very likely to me it has problems :-). >> Also, I'm not 100% sure we should make the getuid() check return a hard >> error in user space. Let's continue to let the kernel code make the access >> control decision here. > > I did the check in user space so that I could read the fstab file, and know > that the volume was allowed to be user-[un]mounted. I suppose, though, that > I could set the flags in user space, then pass that to the kernel for the > actual access control decision as you say. I'm not entirely clear on what ideal is, but one possibility is to allow the user mount bit to determine whether the mount system call is invoked with privilege. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403232730.E76562>