From owner-freebsd-jail@FreeBSD.ORG Mon Jun 29 17:43:43 2009 Return-Path: Delivered-To: jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB511065670 for ; Mon, 29 Jun 2009 17:43:43 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id A69F48FC1A for ; Mon, 29 Jun 2009 17:43:43 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from [192.168.217.128] (gw-wifi.oremut02.us.wh.verio.net [198.65.169.23]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n5THVD8u039717; Mon, 29 Jun 2009 11:31:14 -0600 (MDT) Message-ID: <4A48FA49.70600@FreeBSD.org> Date: Mon, 29 Jun 2009 11:30:49 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090109) MIME-Version: 1.0 To: Alexander Leidinger References: <20090627122519.00002b84@unknown> <20090627104704.Y22887@maildrop.int.zabbadoz.net> <20090627140803.00006830@unknown> <20090627121818.P22887@maildrop.int.zabbadoz.net> <20090627162424.00007289@unknown> In-Reply-To: <20090627162424.00007289@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jail@FreeBSD.org, "Bjoern A. Zeeb" Subject: Re: Switching /etc/rc.d/jail to new syntax (+ new features) 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: Mon, 29 Jun 2009 17:43:44 -0000 Alexander Leidinger wrote: >>>>> at http://www.leidinger.net/FreeBSD/current-patches/jail.diff I >>>>> have a patch to switch the jail rc script to the new jail >>>>> (8-current) syntax. This includes new config options for a jail >>>>> (see etc/defaults/rc.conf after patching). The patch also contains >>>>> my X-in-a-jail stuff (feel free to ignore this part, it's disabled >>>>> by default). >>>>> >>>>> If you do not make any config change, you will be able to see all >>>>> mounted filesystems of the entire machine. To get back to the >>>>> previous behavior, you have to add a config option: >>>>> jail_XXX_startparams="enforce_statfs=2" >>>>> >>>>> This config option can also take other jail parameters like >>>>> allow.sysvipc and other ones described in the jail man-page >>>>> (additional parameters need to be space separated). >>>>> >>>>> Feedback welcome. >>>>> >>>> 1) it break various things that will no longer work >>>> >>> As mentioned, it "breaks" the statfs part. If there's anything >>> else, be more specific please. >>> >> v6, noIP, ... >> > > I didn't change the IP handling in the rc script. Does this mean > jail(8) works differently regarding the address parsing when called > with the new parameters instead of the old options? > > I didn't test anything regarding ipv6, but as long as jail(8) doesn't > behave differently with the new calling syntax compared with what we > have in the tree, then the behavior is not differnt from what we have. > If it behaves differently, this can be fixed in the script. > There is a difference. Under the old options, IPv4 and IPv6 addresses are mixed into the single fixed argument, and then are parsed to determine which kind they are - both by jail(8) and rc.d/jail. Under the new parameter-based command line, IPv4 addresses and IPv6 address go with ip4.addr and ip6.addr respectively. The rc.d/jail code that brings up addresses on an interface can be modified to decide which argument the address goes with. I've given Bjoern a patch based on yours that handles this as well as the allow.* systctls (though I missed the statfs part). He still has the larger disagreements he mentioned though, so I'm working now toward a more comprehensive solution. >>>> 2) it's not a poper solution >>>> >>> The proper solution for the statfs part would be, that jail(8) >>> defaults to =2 if nothing is specified. Alternatively I can get >>> convinced that we should do a default for it in defaults/rc.conf if >>> nothing is specied for startparams for a particular jail (like we >>> have for some other things), but this would not be as good as if >>> jail(8) would handle it itself. >>> >>> If you do not talk about the statfs part but in a more generic way, >>> what would be a proper solution in your eyes? >>> >> A proper solution would be a proper mgmt system ready for the future >> instead of continuting to hack up rc.d/jail via option fo bar baz and >> another 17000 of them. >> But this is nothing I'll discuss today while things aren't fully >> shaken out yet. >> > > And I assume from what you say, that such a new mgmt system will not be > ready for 8.0. Whatever it will be, it sounds like it will be different > from what we have ATM, so I don't think it will be something which will > replace the current approach in 8-stable, but will be available > additionally, if at all. > > >> For now what used to work should continue to work and not break. >> Everything else on top of that needs to be done properly and not in a >> rainy-midnight-drive-by. >> > > This is not a drive-by. I provide a patch for discussion which allows > to use some new features in 8.0 which doesn't break when someone > updates from 7.x. Some small enhancement which doesn't break backwards > compatibility is always better than no improvement at all. It may not > handle all cases, but for this reason I ask people to test it. After > that some things can maybe fixed, and after that it can be evaluated if > it is worth to commit or not. > > I don't even urge to rush this in before 8.0. I just offer it now, so > that people can actually use some new features. I had to write this > anyway, as without the new syntax I wouldn't have been able to use my > enhancement to run X in a jail, which I ported to the new syntax. If > people think it is useful for 8.0 and nothing better is available for > 8.0, it should be shipped with 8.0 IMO (if nothing breaks), but if it > isn't, I don't care, as I have it for where I need it. > > Bye, > Alexander. > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" >