Date: Mon, 3 Apr 2006 23:35:21 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "Marc G. Fournier" <scrappy@hub.org> Cc: pjd@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail Message-ID: <20060403233030.W76562@fledge.watson.org> In-Reply-To: <20060403160231.P947@ganymede.hub.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060403132401.I947@ganymede.hub.org> <20060403174952.E76562@fledge.watson.org> <20060403160231.P947@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403233030.W76562>