Date: Fri, 19 Nov 2004 13:14:50 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys msg.h sem.h shm.h Message-ID: <Pine.NEB.3.96L.1041119131042.92822G-100000@fledge.watson.org> In-Reply-To: <xzp8y8yhvrb.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Nov 2004, Dag-Erling Sm=F8rgrav wrote: > Robert Watson <rwatson@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041119131042.92822G-100000>