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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
