Date: Tue, 4 Apr 2006 12:46:58 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail Message-ID: <20060404124313.B76562@fledge.watson.org> In-Reply-To: <20060404114107.GJ683@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060404124313.B76562>