Re: new feature: private IPC for every jail

On Tue, 2006-Apr-04 12:46:58 +0100, Robert Watson wrote:
>On Tue, 4 Apr 2006, Peter Jeremy wrote:
>>By merging the prison ID into the IPC ID, a non-jailed process can be 
>>allowed to see (and control) jailed IPC without needing any changes to 
>>ipcs/ipcrm.  A non-jailed process won't be able to attach by key but would 
>>be able to attach by ID.
>
>I guess I'm asking a more specific question: you're suggesting treating the 
>prison ID as a logical, but transparent, extension to the key.  Are you 
>suggesting actually changing the way values for the ID field are assigned, 
>or are you suggesting we continue to allocate and manage IDs as we do 
>currently?

Currently, the ID number comprises a pool number and a generation
number (16 bits of each).  I'm suggesting that the algorithm be
changed so that the ID number comprises a pool number, a generation
number and a prison ID (or 0 if outside a prison).  My initial
suggestion is 10, 10 and 12 bits, respectively, but they will
probably need to be tunable since I gather some users run very
large numbers of jails.

>Would it make more sense to simply allocate ID's sequentially, and simply 
>not allow access to objects with a non-matching prison?  If the ID value is 
>entirely opaque, there's no real reason to assign a meaning to it, 
>especially if it leads to potential collisions if, say, the prison ID space 
>becomes large and sparse (due to lots of stopping and starting of prisons 
>over a long run).

The difficulty of a totally opaque ID is mapping it to an actual
instance. Currently, all SysV IPC types have fixed, system-wide limits
on the number of identifiers that exist: msgmni, semmni and shmmni.
FreeBSD (and probably other implementations) therefore allocate fixed-
size arrays of identifiers and use a simple/cheap algorithm to map
from an ID to the array slot (modulo in Tru64, masking in FreeBSD),
combined with a generation count to catch attempts to reuse an old
identifier.

I believe that the IPCID_TO_{IX,SEQ}() and IXSEQ_TO_IPCID() macros
are used for all translations so changing the mapping algorithm
is not out of the question.  The requirements are:
- Given an ID, it must be cheap to locate the IPC object instance.
  (This operation has to be carried out on each IPCop() call).
- It must be possible to determine if the number of existing objects
  is at the system limit and, if not, allocate a new object instance.
- A management tool (ipcs) much be able to determine all the valid IDs.

Given a suitable hashing algorithm then a totally opaque ID does offer
advantages because there are no longer any arbitrary restrictions on
parts of the ID.

-- 
Peter Jeremy