Date: Mon, 3 Apr 2006 01:57:17 -0300 (ADT) From: "Marc G. Fournier" <scrappy@postgresql.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: <20060403015547.M947@ganymede.hub.org> In-Reply-To: <20060403043711.GB76193@heff.fud.org.nz> References: <20060402232832.M947@ganymede.hub.org> <20060402234459.Y947@ganymede.hub.org> <27417.1144033691@sss.pgh.pa.us> <20060403031157.GA57914@xor.obsecurity.org> <27515.1144034269@sss.pgh.pa.us> <20060403032130.GA58053@xor.obsecurity.org> <20060403002830.W947@ganymede.hub.org> <20060403034101.GA58429@xor.obsecurity.org> <20060403035911.GA76193@heff.fud.org.nz> <20060403011401.I947@ganymede.hub.org> <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. 'k, first question is 'what information leak' are we trying to protect from? to 'make postgres a bit happier', all that needs to be fixed, from what I can tell, is that cr_cansignal() needs to work for signal 0, but no other signals ... what risk of information leak does that create? ---- 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?20060403015547.M947>