On Tue, 2006-Apr-04 12:46:58 +0100, Robert Watson wrote:
On Tue, 4 Apr 2006, Peter Jeremy wrote:
By merging the prison ID into the IPC ID, a non-jailed process can be
allowed to see (and control) jailed IPC without needing any changes to
ipcs/ipcrm. A non-jailed process won't be able to attach
On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote:
(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),
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote:
(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,
Robert Watson wrote:
Hmm. This sounds like it might be workable. To make sure I understand
your proposal:
- We add a new prison ID field to the in-kernel description of each
segment,
semaphore, message queue, etc. This is initialized to the prison ID
of the
process creating the
Koen Martens wrote:
FWIW, I already implemented this once for 5.x a while back, but
abandoned the project due to lack of time back then. If no-one else
is going to pick this up, i might try and dig up that code again,
and port it to 6.x, since this feature is still quite high on my
wish
On Tue, 4 Apr 2006, Koen Martens wrote:
FWIW, I already implemented this once for 5.x a while back, but abandoned
the project due to lack of time back then. If no-one else is going to pick
this up, i might try and dig up that code again, and port it to 6.x, since
this feature is still quite
On Tue, 2006-Apr-04 11:47:14 +0100, Robert Watson wrote:
Hmm. This sounds like it might be workable. To make sure I understand
your proposal:
- We add a new prison ID field to the in-kernel description of each segment,
- shmget(), et al, will, in addition to matching the key when searching for
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Tue, 2006-Apr-04 11:47:14 +0100, Robert Watson wrote:
Hmm. This sounds like it might be workable. To make sure I understand
your proposal:
- We add a new prison ID field to the in-kernel description of each segment,
- shmget(), et al, will, in
Robert Watson wrote:
Would it make more sense to simply allocate ID's sequentially, and
simply not allow access to objects with a non-matching prison? ..
This depends on the expected size of the system-wide pool; sequential
allocation invites sequential searches of the name/id-space when
Hello!
On Mon, 3 Apr 2006, Julian Elischer wrote:
(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),
On Tue, 4 Apr 2006, Dmitry Pryanishnikov wrote:
However, I can't find info whether / is legal as the 1st character of IPC
object ID. If yes, we should use another prefix. This approach won't work if
there are no restriction on IPC object IDs 1st character. Are there any?
System V IPC object
Robert Watson wrote:
On Tue, 4 Apr 2006, Peter Jeremy wrote:
On Mon, 2006-Apr-03 16:34:59 +0100, Robert Watson wrote:
(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
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471
[kernel] [patch] new feature: private IPC for every jail
Its an ancient, 4.x patch for having private IPC in a jail ... not sure how
hard it would be to bring it up to 6.x / -current standards
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
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
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
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
Robert Watson wrote:
On Mon, 3 Apr 2006, Marc G. Fournier wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471
[kernel] [patch] new feature: private IPC for every jail
Its an ancient, 4.x patch for having private IPC in a jail ... not
sure how hard it would be to bring it up to 6
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
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48471
[kernel] [patch] new feature: private IPC for every jail
Its an ancient, 4.x patch for having private IPC in a jail ... not sure
how hard it would be to bring it up to 6.x / -current standards though ...
but it seems like something 'good
19 matches
Mail list logo
