From owner-freebsd-jail@freebsd.org Tue Jan 22 10:40:04 2019 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE5D114B7B2D for ; Tue, 22 Jan 2019 10:40:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2E23D85869 for ; Tue, 22 Jan 2019 10:40:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.ysv.freebsd.org (Postfix) id DCC3114B7B2C; Tue, 22 Jan 2019 10:40:03 +0000 (UTC) Delivered-To: jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B897214B7B2B for ; Tue, 22 Jan 2019 10:40:03 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 0A8EC85866 for ; Tue, 22 Jan 2019 10:40:02 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 32A1BA91E0; Tue, 22 Jan 2019 11:39:59 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDJokTtCUgcK; Tue, 22 Jan 2019 11:39:58 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 510F7A91DF; Tue, 22 Jan 2019 11:39:58 +0100 (CET) Subject: Re: delegating ZFS of jail's root directory To: "Michael W. Lucas" , jail@freebsd.org References: <20190121164242.GB91955@mail.michaelwlucas.com> From: Willem Jan Withagen Message-ID: <946528bf-f9a9-724f-b4c0-1a734800d16d@digiware.nl> Date: Tue, 22 Jan 2019 11:39:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190121164242.GB91955@mail.michaelwlucas.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 10:40:04 -0000 On 21-1-2019 17:42, Michael W. Lucas wrote: > Hi, > > Two more book research questions, sorry. If the answer is "it doesn't > work that way," cool, I'll document and move on. It looks like ZFS > delegation isn't widely used. > > 1) It seems I can successfully delegate managing ZFS datasets to a jail, > sort of. A restart removes my ability to destroy and rename datasets I > created, though. > > 2) I can't delegate the jail's root to the jail. Obvious question: CAN > you delegate a jail's root dataset, or am I chasing an impossibility > here? > > Details: > > Real hardware, running yesterday's -current: > > FreeBSD storm 13.0-CURRENT FreeBSD 13.0-CURRENT r343219 GENERIC amd64 > > > Here's my jail.conf. > > exec.start="sh /etc/rc"; > exec.stop="sh /etc/rc.shutdown"; > > filedump { > host.hostname="filedump.mwl.io"; > ip4.addr="203.0.113.224"; > path="/jail/filedump/zroot"; > persist=true; > mount.devfs=true; > allow.mount=true; > allow.mount.zfs=true; > enforce_statfs=1; > exec.poststart="/sbin/zfs jail filedump jail/filedump/zroot"; > exec.poststop="/sbin/zfs unjail filedump jail/filedump/zroot"; > } > > /jail/filedump/zroot contains FreeBSD 12.0 base.tgz extract. > > # ls /jail/filedump/zroot/ > .cshrc dev media root var > .profile etc mnt sbin > COPYRIGHT jail net sys > bin lib proc tmp > boot libexec rescue usr > > Initial ZFS "jailed" parameter: > > # zfs get -r jailed jail/filedump > NAME PROPERTY VALUE SOURCE > jail/filedump jailed off default > jail/filedump/zroot jailed off default > jail/filedump/zroot/cdr jailed on local > jail/filedump/zroot/home jailed on local > jail/filedump/zroot/home/mwl jailed on inherited from jail/filedump/zroot/home > > > Running "service jail start filedump" gives me a working jail. I can > create and destroy datasets. > > root@filedump:~ # zfs create jail/filedump/zroot/home/abc > root@filedump:~ # zfs destroy jail/filedump/zroot/home/abc > > Gonna recreate that dataset for testing purposes: > > root@filedump:~ # zfs create jail/filedump/zroot/home/abc > > Now back to the host, restart the jail, and: > > root@filedump:~ # zfs destroy jail/filedump/zroot/home/abc > cannot unmount '/jail/filedump/zroot/home/abc': Operation not permitted > > I created this dataset within the jail, and can manage it only so long > as it's the same jail instance. A restart wrecks my ability to manage > the dataset. > > > > Second problem: > > I would also like to delegate management of the jail's root fileset, > so on the host I run: > > # zfs set jailed=on jail/filedump/zroot > # service jail start filedump > Starting jails: cannot start jail "filedump": > jail: filedump: mount.devfs: /jail/filedump/zroot/dev: No such file or directory > . > > Which--of course, the root dir isn't mounted, so /dev can't be mounted. > > > I'm vaguely confident I've heard of people delegating management of > the root dataset to the jail, though I can't find it. Am I > misremembering? Hi Michael, I think I asked that question a some time ago, to be able to run a ceph-setup script in a jail.... The basic answer was that the jail needs to have access to /dev/zfs in the jail to be effectively controlling zfs. But then I think you delegate the whole set of zfs capabilities to the jail. Which in my case was not a problem. But if you want to use a jail as separation of control, then this will be way too liberal. There is a set of configs for devfs in /etc. See `man -k devfs` But I've not used this in the end. --WjW