new feature: private IPC for every jail

[Robert Watson]

On Mon, 3 Apr 2006, Marc G. Fournier wrote:

> On Mon, 3 Apr 2006, Robert Watson wrote:
>
>> So the question is this: if you load System V IPC support after you start a 
>> jail, how do we handle jails that have already started? Do we go out and 
>> create new name spaces for jails already started (a problem for method (1), 
>> because it implies System V IPC will have pretty intimate knowledge of 
>> jails, and know how to walk lists, etc), do we deny access to System V IPC 
>> for jails not present when it was loaded?  Likewise, although we tend to 
>> refer to the different IPC mechanisms as in a single category, System V 
>> IPC, there are actually three name spaces, and the functionality for each 
>> can be loaded separately.
>
> Stupid question, but why does a namespace need to be created prior to a 
> process in the jail needing it?  "if jail requests IPC, and IPC is loaded, 
> then create namespace at that point" ... ?

In principle, it can be done any time, but there are some nice simplifying 
assumptions about doing it up-front: among these is that the point of jail 
creation is very useful from a security perspective because you're not running 
contained code at that point, only code that's sufficiently privileged to 
perform the jail creation operation, and that you can avoid extra 
synchronization (locking) of the name space reference to make sure it's 
acessed and allocated with reasonable atomicity.  It should be possible to 
allocate on demand, although there could be catches I haven't thought of by 
virtue of not trying it.

Robert N M Watson