On Sun, 2 Apr 2006, Kris Kennaway wrote:
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
Kris Kennaway <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
