2011/8/7 Simon L. B. Nielsen <si...@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-a...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" > _______________________________________________ freebsd-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
