freebsd stable - Dec 2016 - Is System V IPC namespace still shared across jails?

With the new jail parameters, new namespaces for SysV IPC are possible
on FreeBSD 11.

For those ezjail users, add something like this to the jail's config
after creating it using 'ezjail-admin create':

 export jail_postgres_parameters="sysvmsg=new sysvsem=new sysvshm=new"

Cheers,

  Christian

---

man 8 jail
>  ...
>
>  allow.sysvipc
>       A process within the jail has access to System V IPC
>       primitives.  This is deprecated in favor of the per-
>       module parameters (see below).  When this parameter is
>       set, it is equivalent to setting sysvmsg, sysvsem, and
>       sysvshm all to ``inherit''.
>
>  ...
>
>    sysvmsg
>       Allow access to SYSV IPC message primitives.  If set to
>       ``inherit'', all IPC objects on the system are visible to
this
>       jail, whether they were created by the jail itself, the base
>       system, or other jails.  If set to ``new'', the jail will
have
>       its own key namespace, and can only see the objects that it has
>       created; the system (or parent jail) has access to the jail's
>       objects, but not to its keys.  If set to ``disable'', the
jail
>       cannot perform any sysvmsg-related system calls.
>
>     sysvsem, sysvshm
>       Allow access to SYSV IPC semaphore and shared memory primitives,
>       in the same manner as sysvmsg.
>
>  ...

2016-12-12 20:38, Christian Schwarz wrote:
> With the new jail parameters, new namespaces for SysV IPC are possible
> on FreeBSD 11.
> 
> For those ezjail users, add something like this to the jail's config
> after creating it using 'ezjail-admin create':
> 
> export jail_postgres_parameters="sysvmsg=new sysvsem=new
sysvshm=new"
> 
> Cheers,
>   Christian

Thank you, this is it!
I missed it in the JAIL(8) man page, and is not mentioned in release 
notes.


Now if only the iocage would recognized the sysvmsg, sysvsem, and 
sysvshm
options:

# iocage set sysvmsg='new' xxx
   ERROR: Unsupported property: sysvmsg!

I guess I should file a bug report.


   Mark


> man 8 jail
>>  ...
>>  allow.sysvipc
>>       A process within the jail has access to System V IPC
>>       primitives.  This is deprecated in favor of the per-
>>       module parameters (see below).  When this parameter is
>>       set, it is equivalent to setting sysvmsg, sysvsem, and
>>       sysvshm all to ``inherit''.
>>  ...
>> 
>>    sysvmsg
>>       Allow access to SYSV IPC message primitives.  If set to
>>       ``inherit'', all IPC objects on the system are visible to
this
>>       jail, whether they were created by the jail itself, the base
>>       system, or other jails.  If set to ``new'', the jail will
have
>>       its own key namespace, and can only see the objects that it has
>>       created; the system (or parent jail) has access to the jail's
>>       objects, but not to its keys.  If set to ``disable'', the
jail
>>       cannot perform any sysvmsg-related system calls.
>> 
>>     sysvsem, sysvshm
>>       Allow access to SYSV IPC semaphore and shared memory primitives,
>>       in the same manner as sysvmsg.
>>> Regarding installation of PostgreSQL in a FreeBSD jail, the web
hold
>>> plenty of
>>>  warnings/advice that each postgres instance should have a unique 
>>> UID, otherwise
>>> they stumble across each other's feet:
>>> 
>>> | allow.sysvipc
>>>  |   A process within the jail has access to System V IPC
primitives.
>>> In the
>>>  | current jail implementation, System V primitives share a single 
>>> namespace
>>>  | across the host and jail environments, meaning that processes 
>>> within a jail
>>>  | would be able to communicate with (and potentially interfere
with)
>>> processes
>>>  | outside of the jail, and in other jails.
>>> 
>>> 
>>> Is this still the case in FreeBSD 11.0 ???
>>> 
>>> I remember hearing rumors that the System V namespace
>>> no longer is (will?) be shared across jails.
>>> (Couldn't find it being mentioned in release notes.)
>>> 
>>>   Mark