From owner-freebsd-current@FreeBSD.ORG Tue Apr 4 11:47:00 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 4863A16A401; Tue, 4 Apr 2006 11:47:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B506843D46; Tue, 4 Apr 2006 11:46:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BE90246BB3; Tue, 4 Apr 2006 07:46:58 -0400 (EDT) Date: Tue, 4 Apr 2006 12:46:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20060404114107.GJ683@turion.vk2pj.dyndns.org> Message-ID: <20060404124313.B76562@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> <20060404114107.GJ683@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Tue, 04 Apr 2006 11:47:00 -0000 On Tue, 4 Apr 2006, Peter Jeremy wrote: > On Tue, 2006-Apr-04 11:47:14 +0100, Robert Watson wrote: >> 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, >> - 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. >> - 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. > > Yes. And prison.pr_id can't be 0 so 0 makes a good choice as the unjailed > flag. > >> Is it necessary, as you suggest, to change the IPC ID name space at all? > > 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? >> 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? > > Those macros are all protected by #ifdef _KERNEL so a portable application > can't assume anything about them (I know Tru64 uses a different algorithm to > combine the pool and generation number). > > My suggestion is something along the lines of: > #define IPCID_TO_IX(id) ((id) & 0x03ff) > #define IPCID_TO_SEQ(id) (((id) >> 10) & 0x03ff) > #define IPCID_TO_PRID(id) (((id) >> 20) & 0x0fff) > #define IXSEQ_TO_IPCID(ix,perm,prid) (((prid) << 20) | ((perm).seq << 10) | ((ix) & 0x03ff)) 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). Robert N M Watson