Re: new feature: private IPC for every jail

From: Marc G. Fournier <scrappy_at_hub.org>
Date: Mon, 3 Apr 2006 13:42:24 -0300 (ADT)
On Mon, 3 Apr 2006, Robert Watson wrote:

> (1) The fact that system v ipc primitives are loadable, and unloadable, 
> which requires some careful handling relating to registration order, 
> etc.

For this one, I'm lost at the issue ... if not loaded, jail processes just 
couldn't attach ... if loaded, and you try to unload, while there are 
shared memory segments in play, don't unload ... or is there something i'm 
missing here? What happens now, if I load ipc, start up postgresql and 
then try to unload ipc?  I hardcode all the stuff I use in my kernel, so 
don't use the load/unload mechanism, so can't test this easily ...

> (2) The name space model for system v ipc is flat, so while it's 
> desirable to allow the administrator in the host environment to monitor 
> and control resource use in the jail (for example, delete allocated but 
> unused segments), doing that requires developing an administrative model 
> for it.

Again, you've lost me here ... how is that different then not using a 
jail?  from the root server, one does an 'ipcs -a' and ipcrm as required 
... the only thing I could think of 'being a nice thing' here is to maybe 
add a 'jail' value, simpler to what is in proc, so that you know what 
segments below to a specific jail ...

I'm free to admit that I may be missing something you are seeing as 
obvious, mind you ;)

For instance, are you suggesting that 'root' in the jail himself could 
issue ipcs -a and ipcrm?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy_at_hub.org           Yahoo!: yscrappy              ICQ: 7615664
Received on Mon Apr 03 2006 - 14:42:33 UTC

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