Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Aug 2011 12:37:49 +0200
From:      "Simon L. B. Nielsen" <simon@nitro.dk>
To:        Jamie Gritton <jamie@FreeBSD.org>
Cc:        freebsd-jail@FreeBSD.org, freebsd-arch@FreeBSD.org
Subject:   Re: New jail(8) with configuration files, not yet in head
Message-ID:  <005878F6-3CF5-482E-98E8-E5E4B8CA6C99@nitro.dk>
In-Reply-To: <4E25BB7C.4090106@FreeBSD.org>
References:  <4E114EA9.4000605@FreeBSD.org> <20110718190839.GA81421@psconsult.nl> <4E25BB7C.4090106@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 19 Jul 2011, at 19:14, Jamie Gritton wrote:

> On 07/18/11 13:08, Paul Schenkeveld wrote:
>=20
>> Although I really like this new functionality, there is one issue =
that
>> I am concerned about.  Should all this functionality be integrated =
into
>> the jail(8) command?
>=20
> This project came from a desire to improve the jail startup procedure =
in rc.d/jail, which remains stuck handling the old fixed-parameter =
jails. Rather that continue to extend an already unwieldy number of =
rc.conf shell variables, I opted to add a configuration file like other =
subsystems use (e.g. apmd, devd).  The new jail pseudo-parameters added =
to the config file exist mostly to match the existing rc.d/jail =
functionality - the mount.* and exec.* parameters are direct analogs to =
rc.conf shell variables.  Some other parameters match the command-line =
options of the existing jail(8).

[This is less a mail to Jamie and more me getting around to publicly =
supporting they way it's done]

A thing to note is also that when starting a jail you have to be really =
careful to do all of the related operations in the right order and in a =
safe manner. E.g. mounting file systems are only safe in some =
circumstances (ref: symlink attacks) so that's one reason I think the =
new approach is the right one. Also try reading the current rc.d/jail =
code for checking for those symlinks etc... not pretty.

There are also some other quirks which means a slightly more =
comprehensive program is better.  E.g. current rc.d jails have a bug =
where they can actually fill /tmp if they produce a lot of console =
output due to redirection to temp file (this is rarely a real problem so =
I never gotten around to trying to fix it).

Bloat is of course a concern, but I don't think that risk outweigh the =
benefits of Jamie's new work.

There is still room and need for a wrapper management framework (ezjail =
or something close to it) which handles the actual creation, update etc. =
which makes sense as a separate utility not part of jail(8). ezjail =
already uses rc.d/jail heavily so I think it can nicely integrate with =
the new jail(8).

> I wouldn't want to do away with a config file, as that's a much =
cleaner way to define multiple jails than depending on the rc system or =
requiring a "roll your own" approach that is currently the only way to =
use the newer features.

Just reading /etc/rc.d/jail is IMO good proof of this...

> It's clear now that this won't be happening in 9.0.  So none of this =
is in danger of getting pushed through in a hurry.

I really hope that this can go into head shortly after the branch so it =
can hopefully make it into 9.1.

--=20
Simon L. B. Nielsen




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005878F6-3CF5-482E-98E8-E5E4B8CA6C99>