cvs commit: src/sys/sys msg.h sem.h shm.h

[Robert Watson]

On Fri, 19 Nov 2004, Dag-Erling Smørgrav wrote:

> Robert Watson <rwatson at FreeBSD.org> writes:
> >   Log:
> >   In the kernel-only portionss of System V IPC objects (messages,
> >   message queues, shared memory segments, and semaphores), add a struct
> >   label pointer, which will hold the MAC labels for the objects.  As a
> >   result of recent work to separate kernel and user space ABIs, this
> >   should not break the ABI for applications using System V IPC, but will
> >   require a rebuild of the ipcs monitoring tool.
> 
> Hmm, you wouldn't also happen to have any plans to move SysV IPC objects
> into per-jail namespaces, would you? 

I've looked at implementing that previously, but I've always run into two
stumbling blocks that left me with an implementation I was uncomfortable
with:

- The loadable/unloadable nature of the System V IPC code makes the
  pluggable aspects of the whole thing rather un-pretty.  It would be very
  tempting to make it so System V IPC modules can't be unloaded.  Among
  other things, one has to figure out how to deal with cases like "The
  jail was created before System V IPC was loaded, so what do we do now?".

- If you have multiple name spaces, it makes it hard for the administrator
  running outside the jail to track and manage IPC resources that are
  leaked in Jails.  ipcs and ipcrm are written under the assumption of a
  single name space, and the whole management infrastructure and APIs
  there will become substantially more complicated if multiple name spaces
  exist.  Especially given that the resource limits for System V IPC are
  both very concrete and global.

So I sort of left it at that -- Jail is a useful middle ground pseudo-hack
that goes for the path of least resistence in implementation.
Unfortunately, System V IPC doesn't really lend itself to that.  The only
really tempting approach to making the name spaces more manageable is to
make use of a pseudo-file system so that we really can do hierarchal
naming.  But that has many downsides itself, not least overhead.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research