Skip site navigation (1)Skip section navigation (2)
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>