Re: Is System V IPC namespace still shared across jails?

[Mark Martinec]

2016-12-13 16:29, Alan Somers wrote:

I've already added support for sysvmsg, sysvsem, and sysvshm to
iocage.  They all default to "new", which means you won't have to do
anything special in your jail config to make postgres work.  You can
find the patch below.  The only reason it hasn't been merged is
because it can't (yet) be made to work correctly on the develop branch
of iocage.  But it works fine on the master branch.

https://github.com/iocage/iocage/pull/370

-Alan


Superb, appreciated!

  Mark




On Tue, Dec 13, 2016 at 8:08 AM, Mark Martinec
 wrote:

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

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is System V IPC namespace still shared across jails?

[Alan Somers]

I've already added support for sysvmsg, sysvsem, and sysvshm to
iocage.  They all default to "new", which means you won't have to do
anything special in your jail config to make postgres work.  You can
find the patch below.  The only reason it hasn't been merged is
because it can't (yet) be made to work correctly on the develop branch
of iocage.  But it works fine on the master branch.

https://github.com/iocage/iocage/pull/370

-Alan

On Tue, Dec 13, 2016 at 8:08 AM, Mark Martinec
 wrote:
> 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
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is System V IPC namespace still shared across jails?

[Mark Martinec]

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

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is System V IPC namespace still shared across jails?

[Christian Schwarz]

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.
>
>  ...

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Is System V IPC namespace still shared across jails?

[Mark Martinec]

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
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"