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>