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