mksnap_ffs(8) is not working while chrooted

[Maxim Sobolev]

Kirk, what you are saying in not applying in our case. The whole FS is
mounted *inside* the chroot. The reason why we are trying to use mksnap_ffs
is to take a clean snapshot to make a compressed version of it without the
need to forcefully zero out free space.

So it looks like the following:

parent# chroot /mnt/chroot /bin/sh
chroot# truncate /tmp/diskimage
chroot# mdconfig -a -f /tmp/diskimage
md0
chroot# newfs md0
chroot# mount /dev/md0 /mnt
[...do stuff with /mnt...]
chroot# mksnap_ffs /mnt/snap
mksnap_ffs: No such file or directory

Perhaps, to work around your concern is to add some flag for the statfs(1)
to normalize f_mntonname for use inside chroot then? I have not tested it
here, but I believe that if I'd strip "/mnt/chroot" prefix inside
mksnap_ffs(8) that would work in our scenario just fine.

-Max

On Tue, Apr 11, 2017 at 11:07 AM, Kirk McKusick <mckusick at mckusick.com>
wrote:

> > From: Maxim Sobolev <sobomax at freebsd.org>
> > Date: Tue, 11 Apr 2017 10:40:58 -0700
> > Subject: mksnap_ffs(8) is not working while chrooted
> > To: Kirk McKusick <mckusick at mckusick.com>,
> >         FreeBSD Filesystems <freebsd-fs at freebsd.org>
> >
> > 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
>
>