From owner-freebsd-current@FreeBSD.ORG Mon Apr 3 16:42:33 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F94116A401; Mon, 3 Apr 2006 16:42:33 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id D128743D5D; Mon, 3 Apr 2006 16:42:26 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 53674823A9D; Mon, 3 Apr 2006 13:42:25 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 26926-10; Mon, 3 Apr 2006 13:42:26 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id CC9F9823A87; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id CC5123C9A2; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id C6FF83C8FA; Mon, 3 Apr 2006 13:42:24 -0300 (ADT) Date: Mon, 3 Apr 2006 13:42:24 -0300 (ADT) From: "Marc G. Fournier" To: Robert Watson In-Reply-To: <20060403163220.F36756@fledge.watson.org> Message-ID: <20060403132401.I947@ganymede.hub.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 16:42:33 -0000 On Mon, 3 Apr 2006, Robert Watson wrote: > (1) The fact that system v ipc primitives are loadable, and unloadable, > which requires some careful handling relating to registration order, > etc. For this one, I'm lost at the issue ... if not loaded, jail processes just couldn't attach ... if loaded, and you try to unload, while there are shared memory segments in play, don't unload ... or is there something i'm missing here? What happens now, if I load ipc, start up postgresql and then try to unload ipc? I hardcode all the stuff I use in my kernel, so don't use the load/unload mechanism, so can't test this easily ... > (2) The name space model for system v ipc is flat, so while it's > desirable to allow the administrator in the host environment to monitor > and control resource use in the jail (for example, delete allocated but > unused segments), doing that requires developing an administrative model > for it. Again, you've lost me here ... how is that different then not using a jail? from the root server, one does an 'ipcs -a' and ipcrm as required ... the only thing I could think of 'being a nice thing' here is to maybe add a 'jail' value, simpler to what is in proc, so that you know what segments below to a specific jail ... I'm free to admit that I may be missing something you are seeing as obvious, mind you ;) For instance, are you suggesting that 'root' in the jail himself could issue ipcs -a and ipcrm? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664