Re: new feature: private IPC for every jail

From: Koen Martens <fbsd_at_metro.cx>
Date: Tue, 04 Apr 2006 13:04:01 +0200
Robert Watson wrote:
>
> 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
> segment,
>   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 already
>   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.
> 
> - 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 question.
> 
> This prevents a future jail from turning up with the same ID and seeing
> old shared memory (etc) segments.

FWIW, I already implemented this once for 5.x a while back, but
abandoned the project due to lack of time back then. If no-one else
is going to pick this up, i might try and dig up that code again,
and port it to 6.x, since this feature is still quite high on my
wish list..

Best,

Koen

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/
Received on Tue Apr 04 2006 - 09:00:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC