Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2012 09:42:22 +0100
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Martin Matuska <mm@FreeBSD.org>
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
Message-ID:  <20120319094222.Horde.3rlwV5jmRSRPZvFuXTdGj_A@webmail.leidinger.net>
In-Reply-To: <4F665895.1050803@FreeBSD.org>
References:  <201203162130.q2GLUQaw035726@svn.freebsd.org> <20120317163539.00004d8f@unknown> <4F6653C6.6020405@FreeBSD.org> <4F665895.1050803@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Martin Matuska <mm@FreeBSD.org> (from Sun, 18 Mar 2012  
22:50:13 +0100):

> On 18.3.2012 22:29, Martin Matuska wrote:
>> On 17.3.2012 16:35, Alexander Leidinger wrote:
>>> On Fri, 16 Mar 2012 21:30:26 +0000 (UTC) Martin Matuska
>>> <mm@FreeBSD.org> wrote:
>>>
>>>> Author: mm
>>>> Date: Fri Mar 16 21:30:26 2012
>>>> New Revision: 233048
>>>> URL: http://svn.freebsd.org/changeset/base/233048
>>>>
>>>> Log:
>>>>   Unhide /dev/zfs in devfsrules_jail.
>>>>
>>>>   The /dev/zfs device is required for managing jailed ZFS datasets.
>>> This may give more info to a jail (ZFS is in use on this machine) than
>>> what someone may want to provide. I have separate rulesets for jails
>>> without and with ZFS (actually the one without is the default one and
>>> the one with is a new one):
>>> ---snip---
>>> ...
>>>
>>> [devfsrules_unhide_zfs=12]
>>> add path zfs unhide
>>>
>>> ...
>>>
>>> [devfsrules_jail_withzfs=16]
>>> add include $devfsrules_hide_all
>>> add include $devfsrules_unhide_basic
>>> add include $devfsrules_unhide_login
>>> add include $devfsrules_unhide_zfs
>>> ---snip---
>>>
>>> Anyone with arguments why this may be overly paranoid? If not, I would
>>> suggest that we go this way instead.
>>>
>>> Bye,
>>> Alexander.
>>>
>> 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)?

Bye,
Alexander.

-- 
Don't drink when you drive -- you might hit a bump and spill it.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120319094222.Horde.3rlwV5jmRSRPZvFuXTdGj_A>