From owner-cvs-src@FreeBSD.ORG Fri Nov 19 13:16:28 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEFAD16A4CE; Fri, 19 Nov 2004 13:16:28 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5957543D31; Fri, 19 Nov 2004 13:16:28 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iAJDEotE094004; Fri, 19 Nov 2004 08:14:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iAJDEox4094001; Fri, 19 Nov 2004 13:14:50 GMT (envelope-from robert@fledge.watson.org) Date: Fri, 19 Nov 2004 13:14:50 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys msg.h sem.h shm.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 13:16:29 -0000 On Fri, 19 Nov 2004, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: > > Log: > > In the kernel-only portionss of System V IPC objects (messages, > > message queues, shared memory segments, and semaphores), add a struct > > label pointer, which will hold the MAC labels for the objects. As a > > result of recent work to separate kernel and user space ABIs, this > > should not break the ABI for applications using System V IPC, but wil= l > > require a rebuild of the ipcs monitoring tool. >=20 > Hmm, you wouldn't also happen to have any plans to move SysV IPC objects > into per-jail namespaces, would you?=20 I've looked at implementing that previously, but I've always run into two stumbling blocks that left me with an implementation I was uncomfortable with: - The loadable/unloadable nature of the System V IPC code makes the pluggable aspects of the whole thing rather un-pretty. It would be very tempting to make it so System V IPC modules can't be unloaded. Among other things, one has to figure out how to deal with cases like "The jail was created before System V IPC was loaded, so what do we do now?". - If you have multiple name spaces, it makes it hard for the administrator running outside the jail to track and manage IPC resources that are leaked in Jails. ipcs and ipcrm are written under the assumption of a single name space, and the whole management infrastructure and APIs there will become substantially more complicated if multiple name spaces exist. Especially given that the resource limits for System V IPC are both very concrete and global. So I sort of left it at that -- Jail is a useful middle ground pseudo-hack that goes for the path of least resistence in implementation. Unfortunately, System V IPC doesn't really lend itself to that. The only really tempting approach to making the name spaces more manageable is to make use of a pseudo-file system so that we really can do hierarchal naming. But that has many downsides itself, not least overhead. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research