From owner-freebsd-current@FreeBSD.ORG Wed Apr 5 08:55:45 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 F2F9616A420; Wed, 5 Apr 2006 08:55:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3248343D48; Wed, 5 Apr 2006 08:55:44 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail12.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k358tfGl020166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Apr 2006 18:55:42 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k358tfvN001030; Wed, 5 Apr 2006 18:55:41 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k358tf7k001029; Wed, 5 Apr 2006 18:55:41 +1000 (EST) (envelope-from peter) Date: Wed, 5 Apr 2006 18:55:41 +1000 From: Peter Jeremy To: Robert Watson Message-ID: <20060405085541.GC699@turion.vk2pj.dyndns.org> References: <20060403003318.K947@ganymede.hub.org> <20060403163220.F36756@fledge.watson.org> <20060404100750.GG683@turion.vk2pj.dyndns.org> <20060404112938.G76562@fledge.watson.org> <20060404114107.GJ683@turion.vk2pj.dyndns.org> <20060404124313.B76562@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404124313.B76562@fledge.watson.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: 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: Wed, 05 Apr 2006 08:55:45 -0000 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 by key but would >>be able to attach by ID. > >I guess I'm asking a more specific question: you're suggesting treating the >prison ID as a logical, but transparent, extension to the key. Are you >suggesting actually changing the way values for the ID field are assigned, >or are you suggesting we continue to allocate and manage IDs as we do >currently? Currently, the ID number comprises a pool number and a generation number (16 bits of each). I'm suggesting that the algorithm be changed so that the ID number comprises a pool number, a generation number and a prison ID (or 0 if outside a prison). My initial suggestion is 10, 10 and 12 bits, respectively, but they will probably need to be tunable since I gather some users run very large numbers of jails. >Would it make more sense to simply allocate ID's sequentially, and simply >not allow access to objects with a non-matching prison? If the ID value is >entirely opaque, there's no real reason to assign a meaning to it, >especially if it leads to potential collisions if, say, the prison ID space >becomes large and sparse (due to lots of stopping and starting of prisons >over a long run). The difficulty of a totally opaque ID is mapping it to an actual instance. Currently, all SysV IPC types have fixed, system-wide limits on the number of identifiers that exist: msgmni, semmni and shmmni. FreeBSD (and probably other implementations) therefore allocate fixed- size arrays of identifiers and use a simple/cheap algorithm to map from an ID to the array slot (modulo in Tru64, masking in FreeBSD), combined with a generation count to catch attempts to reuse an old identifier. I believe that the IPCID_TO_{IX,SEQ}() and IXSEQ_TO_IPCID() macros are used for all translations so changing the mapping algorithm is not out of the question. The requirements are: - Given an ID, it must be cheap to locate the IPC object instance. (This operation has to be carried out on each IPCop() call). - It must be possible to determine if the number of existing objects is at the system limit and, if not, allocate a new object instance. - A management tool (ipcs) much be able to determine all the valid IDs. Given a suitable hashing algorithm then a totally opaque ID does offer advantages because there are no longer any arbitrary restrictions on parts of the ID. -- Peter Jeremy