Date: Tue, 4 Apr 2006 21:41:07 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: new feature: private IPC for every jail Message-ID: <20060404114107.GJ683@turion.vk2pj.dyndns.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
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 >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? The IPC ID must be treated as a non-persistent opaque number by the application. It's supposed to be treated much as you would an FD - it makes no sense for an application to remember that opening /some/file returned FD 5 last time so you can skip the open by remembering the 5. (Though, unlike FDs, the kernel doesn't actually validate that the ID presented for an IPC operation was returned by an IPC get). > 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)) >I guess another change is also needed: > >- At jail termination, we GC all resources with the prison ID in question. This is probably a good idea but somewhat messier because SysV IPC has no concept of GC (another brain-dead mis-feature). The implementation should be a JKH project - I don't need the feature and can't currently justify the time to implement it. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060404114107.GJ683>