From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 17:14:12 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97FA716A401; Mon, 3 Apr 2006 17:14:12 +0000 (UTC) (envelope-from scrappy@postgresql.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id C70AB43D49; Mon, 3 Apr 2006 17:14:10 +0000 (GMT) (envelope-from scrappy@postgresql.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 4BC19823B89; Mon, 3 Apr 2006 14:14:08 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 34236-04; Mon, 3 Apr 2006 14:14:09 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id 8ED66823B83; Mon, 3 Apr 2006 14:14:07 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 3FF7837DB1; Mon, 3 Apr 2006 14:14:07 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 34968363BD; Mon, 3 Apr 2006 14:14:07 -0300 (ADT) Date: Mon, 3 Apr 2006 14:14:06 -0300 (ADT) From: "Marc G. Fournier" X-X-Sender: scrappy@ganymede.hub.org To: Daniel Eischen In-Reply-To: Message-ID: <20060403140902.C947@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: freebsd-stable@freebsd.org, Andrew Thompson , Kris Kennaway Subject: Re: [HACKERS] semaphore usage "port based"? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 17:14:12 -0000 On Mon, 3 Apr 2006, Daniel Eischen wrote: > 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. The problem is that PostgreSQL uses kill(PID, 0) to determine whether or not another process is running when it tries to allocate a semaphore ... for instance, when it starts up, it tries to semget(54320001); ... if that fails, based on the PID that is attached to that semaphore, it tries to do a kill(PID,0) ... if that fails, it then *takes over* that semaphore ... under 4.x, kill(PID,0) *would* return that a process is running, even if it was in another jail, altho the jail issuing the kill can't see that process, so postgresql would go on to 54320002, and test that ... under FreeBSD 6.x, kill(PID, 0) reports "not in use", so PostgreSQL stomps on that semaphore ... Robert brought up a good point, about recycled PIDs, but Tom Lane's response to that about the fact that we don't care if the process that is running is the one *actually* holding the semaphore, we'd rather err on the side of caution and just move on ... but we need to *know* that we need to move on ... We don't need any more information about that process ID then that it is "currently in use" ... nd I think that is where Andrew was coming from with issueing EPERM rather then ESRCH ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664