new feature: private IPC for every jail
julian at elischer.org
Tue Apr 4 19:26:22 UTC 2006
Robert Watson wrote:
> On Tue, 4 Apr 2006, Peter Jeremy wrote:
>> 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
>>> allow the administrator in the host environment to monitor and
>>> resource use in the jail (for example, delete allocated but unused
>>> segments), doing that requires developing an administrative model
>> 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.
> Hmm. This sounds like it might be workable. To make sure I
> understand your proposal:
> - We add a new prison ID field to the in-kernel description of each
> semaphore, message queue, etc. This is initialized to the prison ID
> of the
> process creating the object at the time of creation.
> - shmget(), et al, will, in addition to matching the key when
> searching for an
> existing object, will also attempt to match the prison ID of the
> object to
> the process. For the sake of completeness, we will use prison ID 0 for
> unjailed processes (or something along those lines). This
> guarantees that
> two jails, or even the host and a jail, will never receive an ID
> allocated to another jail, and in particular, not an ID for an
> object from
> another jail with the same key as might be used in the current jail.
what if a host wants to communicate with a jail?
does it make sense?
at teh moment a host ca see into a jail inmany ways.. (filesystem,
sockets, process space etc.)
> - shmat(), et al, will perform an access control check to confirm that
> if a
> process is jailed, its prison ID matches that of the object.
> Is it necessary, as you suggest, to change the IPC ID name space at
> all? I assume applications do consistently use shmget() to look up
> IDs, and that they can't/don't make assumptions about long-term
> persistence of those mappings across boot (which is effectively what a
> jail restart is? Is the behavior of IPXSEQ_TO_IPCID() something that
> has documented or relied on properties, or are we free to perform a
> mapping from a name (key) to an object (id) in any way we choose?
> I guess another change is also needed:
> - At jail termination, we GC all resources with the prison ID in
> This prevents a future jail from turning up with the same ID and
> seeing old shared memory (etc) segments.
> Robert N M Watson
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-stable