Date: Mon, 3 Apr 2006 08:19:00 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Andrew Thompson <thompsa@freebsd.org> Cc: "Marc G. Fournier" <scrappy@postgresql.org>, freebsd-stable@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <Pine.GSO.4.43.0604030817090.21105-100000@sea.ntplx.net> In-Reply-To: <20060403043711.GB76193@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Andrew Thompson wrote: > On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote: > > > > taking it off of pgsql-hackers, so that we don't annoy them unnecessarily > > ... > > > > 'k, looking at the code, not that most of it doesn't go over my head ... > > but ... > > > > in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one > > want to make the change a bit further up? say in kern_prot.c? wouldn't > > you want to change just cr_cansignal() to allow *just* for 'case 0', when > > someone is just checking to see if a process is already running? I > > wouldn't want to be able to SIGKILL the process from a different jail, > > mind you ... maybe move the check for SIG0 to just before the > > prison_check, since, unless I'm missing something, other then determining > > that a process is, in fact, running, SIG0 is a benign signal? > > > > I think the suggestion was to make this EPERM rather than ESRCH to make > postgres a bit happier, not remove the check entirely. Im not familiar > with that part of the kernel at all, so I cant say what the consequences > will be apart from the obvious information leak. 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. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0604030817090.21105-100000>