[CFR] [PATCH] jail mount/unmount patch

[Kostik Belousov]

On Thu, Jul 28, 2011 at 06:07:52PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Jul 27, 2011 at 10:08:44PM +0200, Martin Matuska wrote:
> > Please review my attached patch.
> > 
> > The patch fixes mount/unmount inside a jail for filesystems with the
> > VFCF_JAIL flag
> > security.jail.mount_allowed=1 is required.
> > For "enforce_statfs == 2" it makes no sense to allow mount/unmount
> > inside a jail so enforce_statfs == 2 implies mount_allowed = 0
> > The filesystems mounted inside a jail have now a corect f_mntonname.
> > 
> > Tested with:
> > zfs - works! (both enforce_statfs=0 and enforce_statfs=1)
> > nullfs (with added VFCF_JAIL flag) - works ! (both enforce_statfs=0 and
> > enforce_statfs=1)
> > tmpfs (with added VFCF_JAIL flag) - works ! (both enforce_statfs=0 and
> > enforce_statfs=1)
> > 
> > I assume other filesystems are going to work correctly, too (e.g nfs).
> > Fore the future, I suggest a option to allow mounting specific
> > filesystems in a jail (e.g. zfs, nullfs, tmpfs).
> > 
> > I consider nullfs mounts harmless inside a jail.
> > 
> > With jailed nullfs and tmpfs we can run tinderbox in a jail!
> 
> In you patch you depend on fact that full path to mount directory is
> passed to the nmount(2) system call. This doesn't have to be true.
> I changed mount(8) to call realpath(3) in mount directory, but I see no
> reason someone calling nmount(2) directly with "./foo" mount dir.
> 
> I think the proper way is to build full path from within the kernel
> using vn_fullpath_global().

It indeed may work if the supplied vnode is a directory, since it
will fall back to the dotdot lookup loop if the namecache is purged.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/zfs-devel/attachments/20110728/7ebd8534/attachment.pgp