From owner-svn-src-all@FreeBSD.ORG Mon Mar 19 08:53:00 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EACF106566C; Mon, 19 Mar 2012 08:53:00 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id CAA0F8FC0C; Mon, 19 Mar 2012 08:52:59 +0000 (UTC) Received: from core2.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id F3AA42FE3F; Mon, 19 Mar 2012 09:52:58 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core2.vx.sk (amavisd-new, unix socket) with LMTP id 3uAEHr9PaxAf; Mon, 19 Mar 2012 09:52:53 +0100 (CET) Received: from [10.0.3.3] (188-167-66-148.dynamic.chello.sk [188.167.66.148]) by mail.vx.sk (Postfix) with ESMTPSA id 83E552FE2A; Mon, 19 Mar 2012 09:52:53 +0100 (CET) Message-ID: <4F66F3E5.2020600@FreeBSD.org> Date: Mon, 19 Mar 2012 09:52:53 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alexander Leidinger References: <201203162130.q2GLUQaw035726@svn.freebsd.org> <20120317163539.00004d8f@unknown> <4F6653C6.6020405@FreeBSD.org> <4F665895.1050803@FreeBSD.org> <20120319094222.Horde.3rlwV5jmRSRPZvFuXTdGj_A@webmail.leidinger.net> In-Reply-To: <20120319094222.Horde.3rlwV5jmRSRPZvFuXTdGj_A@webmail.leidinger.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, pjd@FreeBSD.org, jamie@FreeBSD.org Subject: Re: svn commit: r233048 - head/etc/defaults X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 08:53:00 -0000 On 19. 3. 2012 9:42, Alexander Leidinger wrote: >>> The only disclosed information I know of is whether the zfs module is >>> loaded on your system. >>> Other alternative I was thinking of would be using a new ruleset (e.g. >>> devfsrules_jail_zfs=5). >>> The disadvantage here is that users that already have defined a ruleset >>> with this number should be informed somehow. > > Well... we always have this issue. If the rulsets in defaults changes, > the user has to change his own rulesets. I have a lot of rules on my > system and there was at least one occasion where I had to handle a > change because of this. I don't remember if there was an entry in > UPDATING or not, but I don't think we should make a decission about it > based upon if an user has to renumber his rulesets or not. As the > rulesets do not need to be continous, we may want to add an advise to > the man-page(s) to start at a specifc value for the ruleset-numbers > and reserve everything below for the system. I didn't do this myself, > and I have a lot of rulesets, for me this falls within 'nice to have > but easy to handle'. > >> Btw. jail has access to sysctl(8) and this discloses a *LOT* of >> information, including if ZFS is loaded or not (existence of vfs.zfs) >> and all its settings and statistics, hardware devices, geom devices, >> network card counters and many more. Compared to this is /dev/zfs really >> a minor issue :-) > > I agree. > >> Until we limit the output of sysctl() we don't hide this information >> just by hiding /dev/zfs. > > What about not imported pools. Can I see them in jails or are they > hidden (I don't have one around to test ATM)? Until you delegate a zfs dataset to a jail, the jail does not see any pools or datasets. If you delegate a dataset to a jail, the jail sees information about the delegated dataset, the dataset's pool, the parent datasets of this delegated dataset (=the path from pool up to the delegated dataset) and the descendant datasets, if any. We might want to continue this discussion outside of the svn-src mailing lists. -- Martin Matuska FreeBSD committer http://blog.vx.sk