Date: Wed, 5 Apr 2006 18:55:41 +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: <20060405085541.GC699@turion.vk2pj.dyndns.org> In-Reply-To: <20060404124313.B76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <20060404114107.GJ683@turion.vk2pj.dyndns.org> <20060404124313.B76562@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060405085541.GC699>