Date: Mon, 3 Apr 2006 16:08:56 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <20060403160752.I947@ganymede.hub.org> In-Reply-To: <20060403185046.GC683@turion.vk2pj.dyndns.org> References: <20060403043711.GB76193@heff.fud.org.nz> <Pine.GSO.4.43.0604030817090.21105-100000@sea.ntplx.net> <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. And this is what is losing me ... what security implications does being able to kill(PID, 0) a process pose? I can see allowing kill(PID, TERM) a process in another jail being a very bad thing, but if its just checking whether a PID is in use or not, isn't the security issue minimal? ---- 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?20060403160752.I947>