From owner-freebsd-fs@freebsd.org Tue Apr 11 18:55:23 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 3755CD3AC58 for ; Tue, 11 Apr 2017 18:55:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0768F1533 for ; Tue, 11 Apr 2017 18:55:22 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22b.google.com with SMTP id r16so12551385ioi.2 for ; Tue, 11 Apr 2017 11:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tTSwljkJdLDxNUgZJ4RH1Hkv4pveTPf1UYrUY2CHF38=; b=YJ7q1lIMrCF9ja17nS9D/IWUmwPH0p8bZtrZD0SnP0Vb5Mtwy60ErLpGjXd0dIWV2d QWod7ByFy1m4QS9jhvjBkfYyAZFGT/rLFAL+hBqTCMOYH0gczzoWNaRp0VsnzxVIFngb 5Q4I8CS6YcvPd9OYlwvylhFpfgPZeWCRC5p4Z3iB/YFXkDyPBXXn3ea9UfDZrIB0qlM8 C8mS9wz+j2VSr5o8raRBXlXNyK7Lit92x559NwIUFy9uTemJV1LMvMdzje6KWfXPwrVG wYaI3X3Dc1X/2MYLmwkJNTeZFhaLNiQUe4Zn0wF1S1JvOmjDvIZw4XJkTtJPcXQWr8Oc y/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tTSwljkJdLDxNUgZJ4RH1Hkv4pveTPf1UYrUY2CHF38=; b=n0IubCX6NyTt0A6iX8Vcnk/EbmUcfK2XdaIfFieM5FDmB/TtDNKUmAoWiEfqyfF1+o bHUF266tdrUn0tUVZtDNN1jZmQ1FKhhSyFGT8NQVkdg1b3yy3AQhtQS7lXRAJnfeLu9P L/9crI1ngBQ29sUCrRhAU2jI3q2VECye5DpyboILoh5YNjth08GmaD9+SHZ7TF5ycxQk lexXJZwPpUGcKA0tP2+pqvEduK6U3x5l3Q24hno3fX6iqyTsUOjkEJoto8bM6oonlQTo 8Zb249+Ru2dKlXINU/D8UrjdG4mdCVcaGoC1JX6lpMHWRAJhgI8Os3+aDhFcP/w2XPjH HzXA== X-Gm-Message-State: AN3rC/5o1bUPG1ITQi37YRdT52vdaab029N9J8nMs6eGHwVM191CmYC5 Do8rTN90IjLBCxkSmY6umjvrj5iUvp4lwDw= X-Received: by 10.36.74.196 with SMTP id k187mr18574948itb.49.1491936922059; Tue, 11 Apr 2017 11:55:22 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 11:55:21 -0700 (PDT) In-Reply-To: References: <201704111807.v3BI7PGM001952@chez.mckusick.com> From: Maxim Sobolev Date: Tue, 11 Apr 2017 11:55:21 -0700 X-Google-Sender-Auth: dxHY2yMiFuZeXASrtbfVRgr9bgY Message-ID: Subject: Re: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick Cc: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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:55:23 -0000 Kirk, yes, indeed, it works just fine if I chop out the chroot prefix manually here: [/builder.trunk/usr/src/sbin/mksnap_ffs]$ sudo chroot /builder.trunk sh # truncate -s 100m /tmp/fsimage # mdconfig -a -f /tmp/fsimage md0 # newfs /dev/md0 /dev/md0: 100.0MB (204800 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 25.03MB, 801 blks, 3328 inodes. super-block backups (for fsck_ffs -b #) at: 192, 51456, 102720, 153984 # mount /dev/md0 /mnt # /usr/src/sbin/mksnap_ffs/mksnap_ffs /mnt/mysnap # ls -l /mnt/mysnap -r--r----- 1 root operator 104857672 Apr 11 18:42 /mnt/mysnap # ^D [/builder.trunk/usr/src/sbin/mksnap_ffs]$ git diff diff --git a/sbin/mksnap_ffs/mksnap_ffs.c b/sbin/mksnap_ffs/mksnap_ffs.c index efd9c6b33..b1fba5e16 100644 --- a/sbin/mksnap_ffs/mksnap_ffs.c +++ b/sbin/mksnap_ffs/mksnap_ffs.c @@ -116,7 +116,7 @@ main(int argc, char **argv) iovlen = 0; build_iovec(&iov, &iovlen, "fstype", "ffs", 4); build_iovec(&iov, &iovlen, "from", snapname, (size_t)-1); - build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname, (size_t)-1); + build_iovec(&iov, &iovlen, "fspath", stfsbuf.f_mntonname + 14, (size_t)-1); build_iovec(&iov, &iovlen, "errmsg", errmsg, sizeof(errmsg)); build_iovec(&iov, &iovlen, "update", NULL, 0); build_iovec(&iov, &iovlen, "snapshot", NULL, 0); So my point is that by making this scenario working OOB I don't think we would add any new security issue. This already works if you pass proper path into the nmount(2) and the mount path is inside chroot. In principle I can possibly do some clever trick on the userland only to strip offending prefix f_mntonname here component by component until we can locate the mount dir, but it's likely to be somewhat fuzzy and clearly not suitable for the basesrc repo. -Max On Tue, Apr 11, 2017 at 11:23 AM, Maxim Sobolev wrote: > 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 > wrote: > >> > 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 >> >> >