Re: semaphore usage "port based"?

On Sun, 2 Apr 2006, Kris Kennaway wrote:

> On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
>> Kris Kennaway <kris@obsecurity.org> writes:
>>> On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
>>>> If this is the story, then FBSD have broken their system and must revert
>>>> their change.  They do not have kernel behavior that totally hides the
>>>> existence of the other process, and therefore having some calls that
>>>> pretend it's not there is simply inconsistent.
>>
>>> I'm guessing it's a deliberate change to prevent the information
>>> leakage between jails.
>>
>> I have no objection to doing that, so long as you are actually doing it
>> correctly.  This example shows that each jail must have its own SysV
>> semaphore key space, else information leaks anyway.
>
> By default SysV shared memory is disallowed in jails.

'k, but how do I fix kill so that it has the proper behaviour if SysV is 
enabled?  Maybe a mount option for procfs that allows for pre-5.x 
behaviour? I'm not the first one to point out that this is a problem, just 
the first to follow it through to the cause ;(  And I believe there is 
more then just PostgreSQL that is affected by shared memory (ie. apache2 
needs SysV IPC enabled, so anyone doing that in a jail has it enabled 
also) ...

Basically, I don't care if 'default' is ultra-secure ... but some means to 
bring it down a notch would be nice ... :(

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664