Date: Tue, 04 Apr 2006 12:26:06 -0700 From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@freebsd.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail Message-ID: <4432C84E.8050007@elischer.org> In-Reply-To: <20060404112938.G76562@fledge.watson.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4432C84E.8050007>