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: 7615664Received 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