Date: Tue, 4 Apr 2006 20:07:50 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail Message-ID: <20060404100750.GG683@turion.vk2pj.dyndns.org> In-Reply-To: <20060403163220.F36756@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote: >(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. The SysV SHM name space is made up of a 32-bit user-selected key which is mapped into a 32-bit (system chosen) identifier, which (on FreeBSD) is made up of a 16-bit pool identifier (in the range 0..shmmni-1) and a 16-bit generation counter. At the expense of restricting shmmni, the generation counter and JAIL_MAX, it would seem possible to embed prison.pr_id into the shmid and treat pr_id as an (implicit) part of the key - insisting they must match for jailed processes. Since the name space remains the same, ipcs and ipcrm would not be affected and a non-jailed ipcrm could delete jailed IPC by identifier. On the surface, this approach looks easier than having a distinct name space associated with each prison (as per kern/48471) and has the advantage of allowing non-jailed processes to manage jailed IPC. The disadvantage is restricting the ranges of various counters - though I believe they are overly generous by default. This doesn't really address the problem of SysV IPC and jails becoming more intimately entwined. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060404100750.GG683>