From owner-freebsd-current@FreeBSD.ORG Thu Jul 28 16:31:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32861065672; Thu, 28 Jul 2011 16:31:32 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC7C8FC1F; Thu, 28 Jul 2011 16:31:32 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id p6SGCUxh048618; Thu, 28 Jul 2011 10:12:31 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4E318A69.2080303@FreeBSD.org> Date: Thu, 28 Jul 2011 10:12:25 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110727 Thunderbird/5.0 MIME-Version: 1.0 To: FreeBSD Current References: <4E317951.40601@FreeBSD.org> In-Reply-To: <4E317951.40601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Matuska Subject: Re: [PATCH] jail mount/unmount patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:31:33 -0000 There's a curious asymmetry here: enforce_statfs==1 is checked for munging the name on unmounting, but not on mounting. I see the point on the unmount side, as statfs would give the full un-jailed pathname and an admin would naturally want to unmount what he sees mounted, but without the same logic on the mount side, it would mean the unmount path is different from the mount path which would make fstab not use for mounting inside a jail. But then, enforce_statfs==0 is a strange world to be in anyway. I'm not sure about enforce_statfs!=2 in the privilege check. It seems a reasonable response to a contradictory set of permissions, but then so does the strange case if being able to mount a filesystem and then not being able to see it in statfs. - Jamie On 07/28/11 08:59, Martin Matuska wrote: > Please review my attached patch. > > The patch fixes f_mntonname with mount/unmount inside a jail with allow.mount enabled. > Filesystems mountable in a jail require the VFCF_JAIL flag (currently only ZFS). > > With this patch, mount and unmount works both with enforce_statfs = 0 and enforce_statfs = 1. > I suggest disabling mount/unmount for jails with enforce_statfs = 2, as this is contradictory and does not play well with or without this patch. > > I have successfully tested this patch with ZFS, nullfs and tmpfs. > > To enable nullfs for a jail, you have to modify tmpfs/tmpfs_vfsops.c and recompile the tmpfs module: > -VFS_SET(tmpfs_vfsops, tmpfs, 0); > +VFS_SET(tmpfs_vfsops, tmpfs, VFCF_JAIL); > > To enable tmpfs for a jail, you have to modify nullfs/null_vfsops.c and recompile the nullfs module: > -VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK); > +VFS_SET(null_vfsops, nullfs, VFCF_LOOPBACK | VFCF_JAIL); > > The filesystems can be successfully mounted/unmounted inside a jail and also unmounted from the parent host without problems. > > The mount inside jail, a jail needs allow.mount=1 and enforce.statfs=0 or enforce.statfs=1, for more information see jail(8) > I assume other filesystem not dealing with devices may work correctly with this patch, too (e.g. nfs). > > With jailed nullfs we can run tinderbox in a jail ;) > > Please review, comment and/or test my attached patch. > > Cheers, > mm