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 in the jail (for example, delete allocated but unused
segments), doing that requires developing an administrative model
for
it.
The SysV SHM name space is made up of a 32-bit user-selected key
which is mapped into a 32-bit (system chosen) identifier, which (on
FreeBSD) is made up of a 16-bit pool identifier (in the range
0..shmmni-1) and a 16-bit generation counter.
At the expense of restricting shmmni, the generation counter and
JAIL_MAX, it would seem possible to embed prison.pr_id into the shmid
and treat pr_id as an (implicit) part of the key - insisting they
must match for jailed processes. Since the name space remains the
same, ipcs and ipcrm would not be affected and a non-jailed ipcrm
could delete jailed IPC by identifier.
On the surface, this approach looks easier than having a distinct
name space associated with each prison (as per kern/48471) and has
the advantage of allowing non-jailed processes to manage jailed IPC.
The disadvantage is restricting the ranges of various counters -
though I believe they are overly generous by default.
This doesn't really address the problem of SysV IPC and jails
becoming more intimately entwined.
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 object at the time of creation.
- shmget(), et al, will, in addition to matching the key when
searching for an
existing object, will also attempt to match the prison ID of the
object to
the process. For the sake of completeness, we will use prison ID 0 for
unjailed processes (or something along those lines). This
guarantees that
two jails, or even the host and a jail, will never receive an ID
already
allocated to another jail, and in particular, not an ID for an
object from
another jail with the same key as might be used in the current jail.
what if a host wants to communicate with a jail?
does it make sense?
at teh moment a host ca see into a jail inmany ways.. (filesystem,
sockets, process space etc.)
- shmat(), et al, will perform an access control check to confirm that
if a
process is jailed, its prison ID matches that of the object.
Is it necessary, as you suggest, to change the IPC ID name space at
all? I assume applications do consistently use shmget() to look up
IDs, and that they can't/don't make assumptions about long-term
persistence of those mappings across boot (which is effectively what a
jail restart is? Is the behavior of IPXSEQ_TO_IPCID() something that
has documented or relied on properties, or are we free to perform a
mapping from a name (key) to an object (id) in any way we choose?
I guess another change is also needed:
- At jail termination, we GC all resources with the prison ID in
question.
This prevents a future jail from turning up with the same ID and
seeing old shared memory (etc) segments.
Robert N M Watson
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
