new feature: private IPC for every jail
Marc G. Fournier
scrappy at hub.org
Mon Apr 3 16:42:33 UTC 2006
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
More information about the freebsd-current
mailing list