From owner-freebsd-jail@freebsd.org Fri Dec 9 11:37:18 2016 Return-Path: Delivered-To: freebsd-jail@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 EA454C5D322 for ; Fri, 9 Dec 2016 11:37:18 +0000 (UTC) (envelope-from fbstable@cps-intl.org) Received: from berkeley.cps-intl.org (websense.cps-intl.org [81.137.176.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3DE8A98 for ; Fri, 9 Dec 2016 11:37:18 +0000 (UTC) (envelope-from fbstable@cps-intl.org) Received: from [172.16.0.79] (helo=bdLL65j) by berkeley.cps-intl.org with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1cFJUA-000ONF-Ct; Fri, 09 Dec 2016 11:37:07 +0000 To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-jail References: <584986D0.3040109@quip.cz> <2b6346f8-ed02-0e6d-bd89-106098e7eb2d@cps-intl.org> <58499446.3050403@quip.cz> <5849C5BF.7020005@quip.cz> <584A9179.9060508@quip.cz> From: SK Message-ID: Date: Fri, 9 Dec 2016 11:36:45 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <584A9179.9060508@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.0.79 X-SA-Exim-Mail-From: fbstable@cps-intl.org X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on berkeley.lan.cps-intl.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 Subject: Re: ZFS and Jail :: nullfs mount :: nothing visible from host X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on berkeley.cps-intl.org) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 11:37:19 -0000 Thanks Miroslav, I get the picture now. Please see my reply inline >>> zfs list is good start. I never used zfs from within jail so I cannot >>> comment on permission denied. I don't know what more must be done. >>> >> I'm not sure which list you are referring to. I could not find any zfs >> list in FreeBSD mailing list lists > > I mean your command "zfs list", because normally "zfs list" inside > jail print: "no datasets available" :) > OK, considering that I have the setup as I explained before, and have run zfs jail testJail gT/JailS/testJail, I can see the complete dataset along with the ones that are NOT part of the jail. So, whatever dataset the host can see, I can see from inside the jail. However, I cannot do anything with the dataset from inside the jail. > >> But, what I would really like to have >> >> a) ONLY the relevant datasets for a jail are visible and can be >> manipulated from within the jail. I do not mind if they are visible from >> host (in fact, I might prefer that -- not manipulate, just see and maybe >> take snapshot of what is there -- helps in centralizing backups). But >> the Jails /must not/ see each others' datasets > > > zfs create gT/JailS/testJail > zfs set jailed=on gT/JailS/testJail << Did you set this property? Now this is an interesting bit. I tried this, and as soon as I ran the command, the dataset vanished :P Not only that, I could not run jail any more. Given that gT/JailS is mounted on /JailS and the path parameter in jail.conf is /JailS/testJail, I am not surprised that the jail did not run (it initially complained about not being able to mount /dev, as it cannot find /JailS/testJail/dev) As a workaround, I removed mount.devfs, mount.procfs (that complained too), mount.fdesc (complained too), and then the jail ran But now that I do not have devfs, I could not do anything with zfs -- I could not even see them. So, manipulation from within the jail or outside the jail was no longer possible. > > # (populate & start jail) > > zfs jail testJail gT/JailS/testJail > >> b) if that is not achievable, maybe not allow the jails to see the >> complete dataset hierarchy -- just make them feel that they are where >> they are in a root, but still be able to create datasets that would >> magically show up in the respective jails. This way, the total control >> is from the host itself, where no one has access to, but the datasets >> are restricted to different jails. > > What is visible is controlled by enforce_statfs values. If you create > /tank/jail/alpha and set this path to you first jail no other jail > will know about it. This I believe is where I am stuck at the moment. How do you set this path to the jail? Apparently running zfs jail testJail gT/JailS/testJail did not stop the testJail from seeing gT/Data or gT/JailS/Moving -- in fact, they became visible after that script was run. Any suggestion/pointers is greatly welcome. Out of a little bit of frustration (since I was unable to find any proper documentation on jail.conf -- there is nothing under /etc/default, there is nothing on the man page -- I could not even figure out how to define a zfs as the root/fs for the jail!), I have started looking into ezjail now -- given that everyone seem to claim it can do what I had been unable to do through command line. If my sense and intelligence is well enough, I might be able to find out how it is done. Thanks again for all your help and support, it is truly appreciated. Have a nice weekend. SK > >> Now, for the sysctl values, here they come > > sysctls seem OK, I am out of ideas now. maybe I will have time next > week to try this on my test setup. > > Miroslav Lachman