From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 19:26:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D977E16A401; Tue, 4 Apr 2006 19:26:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outbound7.internet-mail-service.net (outbound7.internet-mail-service.net [216.240.47.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E2C143D53; Tue, 4 Apr 2006 19:26:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by outbound.internet-mail-service.net (Postfix) with ESMTP id EB70F243082; Tue, 4 Apr 2006 12:26:14 -0700 (PDT) Received: from [10.251.17.229] (nat.ironport.com [63.251.108.100]) by idiom.com (8.12.11/8.12.11) with ESMTP id k34JQDi8021285; Tue, 4 Apr 2006 12:26:14 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4432C84E.8050007@elischer.org> Date: Tue, 04 Apr 2006 12:26:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> In-Reply-To: <20060404112938.G76562@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new feature: private IPC for every jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 19:26:22 -0000 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"