New jail(8) with configuration files, not yet in head

joris dedieu joris.dedieu at gmail.com
Sun Aug 7 19:05:26 UTC 2011


2011/8/7 Simon L. B. Nielsen <simon at nitro.dk>:
>
> On 19 Jul 2011, at 19:14, Jamie Gritton wrote:
>
>> On 07/18/11 13:08, Paul Schenkeveld wrote:
>>
>>> 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?
>>
>> 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.

IMHO It's a need. Jails v2 effort  began in 7.2 with multiple ip
support.  /etc/rc.d/jail is clearly unpatchable (see comments in
conf/142972).
It's now reasonable to think that a way to cleanly start jails v2 at
boot time can be hoped form OS primitives.
Joris

>
> --
> Simon L. B. Nielsen
>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>


More information about the freebsd-jail mailing list