From owner-freebsd-jail@FreeBSD.ORG Sun Aug 7 10:38:19 2011 Return-Path: Delivered-To: freebsd-jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55027106567B; Sun, 7 Aug 2011 10:38:19 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id 77F668FC9F; Sun, 7 Aug 2011 10:37:54 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id A1449BCB2A; Sun, 7 Aug 2011 10:37:53 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id yl3IAzCrpp+K; Sun, 7 Aug 2011 10:37:51 +0000 (UTC) Received: from [192.168.4.21] (4304ds2-vlb.1.fullrate.dk [90.184.171.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id D928DBCB20; Sun, 7 Aug 2011 10:37:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Simon L. B. Nielsen" In-Reply-To: <4E25BB7C.4090106@FreeBSD.org> Date: Sun, 7 Aug 2011 12:37:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <005878F6-3CF5-482E-98E8-E5E4B8CA6C99@nitro.dk> References: <4E114EA9.4000605@FreeBSD.org> <20110718190839.GA81421@psconsult.nl> <4E25BB7C.4090106@FreeBSD.org> To: Jamie Gritton X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-jail@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: New jail(8) with configuration files, not yet in head X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 10:38:20 -0000 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