Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Apr 2006 16:32:20 -0300 (ADT)
From:      "Marc G. Fournier" <scrappy@hub.org>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-stable@freebsd.org
Subject:   Re: [HACKERS] semaphore usage "port based"?
Message-ID:  <20060403163039.O947@ganymede.hub.org>
In-Reply-To: <Pine.GSO.4.43.0604031454030.22397-100000@sea.ntplx.net>
References:  <Pine.GSO.4.43.0604031454030.22397-100000@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Daniel Eischen wrote:

> On Tue, 4 Apr 2006, Peter Jeremy wrote:
>
>> On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote:
>>> I don't really see what the problem is.  ESRCH seems perfectly
>>> reasonable for trying to kill (even sig 0) a process from a
>>> different jail.  If you're in a jail, then you shouldn't have
>>> knowledge of processes from other jails.
>>
>> I agree in general.  The problem here is that SysV IPC isn't
>> jail-aware - there's a single SysV IPC address space across the
>> physical system.  This confuses (eg) postgres because it can
>> see the SHM for a postgres instance in another jail but kill(2)
>> claims that the process associated with that SHM doesn't exist.
>>
>> There appear to be two solutions:
>> 1) Add a sysctl to change cr_cansignal() and/or prison_check() to
>>    make processes visible between jails.
>> 2) Change SysV IPC to be jail-aware.
>>
>> The former is trivial - but has a number of security implications.
>> The latter is much harder, there is apparently a RELENG_4 patch in
>> kern/48471 but it's not clear how much work would be necessary to
>> being it up to scratch.
>
> Or:
>
>  3) Run postgres in such a way that it doesn't look for
>     remnant IPC information from other instances (use a
>     per-jail-specific port #?).
>
> Postgres has no business cleaning up after different jailed
> instances of itself, which it wouldn't do if IPC's were
> per-jail.  So since IPC's don't currently work that way,
> account for it by the way you run postgres.

This falls under "well,we broke kill() so that it now reports a PID is not 
in use even though it is, so its has to be the application that fixes it" 
... and you *still* haven't shown *why* kill() reporting a PID is in use, 
even if its not in the current jail, is such a security threat ...

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403163039.O947>