new feature: private IPC for every jail

[Peter Jeremy]

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