From owner-freebsd-fs@freebsd.org Tue Apr 11 17:41:00 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 2EDB5D39C97 for ; Tue, 11 Apr 2017 17:41:00 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 F4170979 for ; Tue, 11 Apr 2017 17:40:59 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x233.google.com with SMTP id a103so11712468ioj.1 for ; Tue, 11 Apr 2017 10:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=1TcX0ojHUB+F4/k7U6APIdIrg29Of2ZXmIZIqcy0cFQ=; b=GnZMXrF9yQOKpMSFJzR21Zj32L5mJ6XfdPubPHL1HInmBGQkv5hVKZFrNPQ/w1k99y cHKuQwJV/leoeIJi/MpzWemMbhoV9g8gGU5YEB9BQ0/IFSCNFACeN4U+IFYQM6LeJ6jY ZqjKopGmwSmqtJl+jToSwzWz8BfCkYct6lPycp0c1+6F2/6n6ojc541yhsAg16/k6ybM w28x0CszHBUZXLNo3pCn7VmqRYC9L3X1Li5KzzW2aeFpds7Z/wEqGk1T9zSzDBSj20Op MZ7WPwGQMo6uiYzt4YViO9xcuNsa/OL2HhtqMXMg13j6QFs+yhxgie31O8E0YDt2KylA e5YA== 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:from:date:message-id:subject :to; bh=1TcX0ojHUB+F4/k7U6APIdIrg29Of2ZXmIZIqcy0cFQ=; b=MDhwZVF32DBRSeIYDm/jZNoLomqZtLLwqjtcU0DHePDoyY+QlAtA906A80BdRlwhwT NQfgFTpiLlVec0T3gFgPCSkwu/4T/4oN/Vl4UoOcKv0dZJEp44h3+n25alACflo8Oha7 KC4vfCuBHk2SeANl+cWwm73LlNE57E0CvxeM9cwE+tGwUyNvMDeBBkDdEOGw/alaD6LA 7wtElzX30H1ONqvUWuyqIm5fdQRKo2StfnYZf3pblE+ES+Ee2/tYvH4HNFlEEf66wGfw BomvhtQtNvXCaNFmfKCxOSEQ9yK8N8VUhnb+w299FHCkkCPNbd6uxIWWkM7MOGCtbM45 ZD3w== X-Gm-Message-State: AFeK/H0x5ODEuJW1ZZQWLyfKVObyGgguwQ/6NpLXexFx2FwBZSTczqIQExISJL3LGy1HZglpGg5gHq9mH3DwKO+A X-Received: by 10.107.171.67 with SMTP id u64mr56783925ioe.102.1491932459146; Tue, 11 Apr 2017 10:40:59 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.112.210 with HTTP; Tue, 11 Apr 2017 10:40:58 -0700 (PDT) From: Maxim Sobolev Date: Tue, 11 Apr 2017 10:40:58 -0700 X-Google-Sender-Auth: G_LBqOcCCtxZZElf9Cpp0OWpnpc Message-ID: Subject: mksnap_ffs(8) is not working while chrooted To: Kirk McKusick , 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 17:41:00 -0000 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