Date: Mon, 3 Apr 2006 15:00:12 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <Pine.GSO.4.43.0604031454030.22397-100000@sea.ntplx.net> In-Reply-To: <20060403185046.GC683@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0604031454030.22397-100000>