From owner-freebsd-fs@freebsd.org Tue Apr 11 18:06:42 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7DE3D3A71C for ; Tue, 11 Apr 2017 18:06:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9055AC8E; Tue, 11 Apr 2017 18:06:41 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v3BI7PGM001952; Tue, 11 Apr 2017 11:07:25 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Kirk McKusick To: Maxim Sobolev Subject: Re: mksnap_ffs(8) is not working while chrooted cc: FreeBSD Filesystems In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1950.1491934045.1@chez.mckusick.com> Date: Tue, 11 Apr 2017 11:07:25 -0700 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:06:42 -0000 > From: Maxim Sobolev > Date: Tue, 11 Apr 2017 10:40:58 -0700 > Subject: mksnap_ffs(8) is not working while chrooted > To: Kirk McKusick , > FreeBSD Filesystems > > Hi Kirk et al, > > I've stumbled upon problem that it is impossible to use mksnap_ffs(8) while > in the chrooted environment. Other utilities that manipulate fs'es (i.e. > mount(8) / umount(8)) work just fine. Quick glance through the code shows > that the problem stems from the fact that mksnap_ffs uses f_mntonname > returned by the statfs(2) system call to fill fspath parameter for the > nmount call. And the statfs() returns f_mntonname path outside chroot. As > far as I can see, there are two options to address this issue. > > 1. Adjust statfs(2) system call to substract chroot prefix while > returning f_mntonname. Similar to what prison_enforce_statfs() function > does for jails. > > 2. Enhance nmount(2) to allow taking FSID in place of mount path to do > resolution using existing flag MNT_BYFSID and adjust mksnap_ffs to use that > instead. This is what umount(8) does to work around the problem. > > Which of two approaches would be preferred solution if any? The second one > seems a bit simpler to me. Please advise. Thanks! > > -Max It is not secure to allow mksnap_ffs(8) to work inside a jail. The issue is that mksnap_ffs takes a snapshot of the entire filesystem. Based on the way that snapshots work in FFS, it is not possible to snapshot only the part of the filesystem that is in the jail. Thus, if you take a snapshot of the entire filesystem and then mount it inside the jail, you will expose parts of the filesystem from outside of the jail to the jail. As such, you should only be able to snapshot a filesystem if it is entirely contained within the jail. If snapshots within jails are important to you, I recommend that you use ZFS which allows you to create per-jail filesystems which you can then snapshot. Kirk McKusick