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.
- 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
