How to implement jail-aware SysV IPC (with my nasty patch)

[kikuchan at uranus.dti.ne.jp]

Hello,

I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be.

I want to run PostgreSQL in each jail without changing UID for each jail.
If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails.
See also;
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471
  http://www.freebsddiary.org/jail-multiple.php
  https://wiki.freebsd.org/Jails
  https://forums.freebsd.org/threads/postgresql-in-jail.51528/

There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel,
but I couldn't find any (other) implementation that works on recent FreeBSD.
I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;(

Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail.
The attached patch can be applied to 10-STABLE (or CURRENT?).

After the patch is applied;
- IPC objects created on parent jail, are invisible to children.
- IPC objects created on neighbor jail, are also invisible each other.
- IPC objects craeted on child jail, are VISIBLE from parent.
- IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE.

I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC.
If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system.

So I need more feedbacks. Could you help me please?
You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail.

Thanks.

--
Kikuchan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jailed-sysvipc-for-stable10-again.patch
Type: text/x-diff
Size: 24986 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150612/336b87d2/attachment.patch>