From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 17:20:06 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 D4B1616A420; Mon, 3 Apr 2006 17:20:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5322943D76; Mon, 3 Apr 2006 17:20:06 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k33HK5sN024260; Mon, 3 Apr 2006 13:20:05 -0400 (EDT) Date: Mon, 3 Apr 2006 13:20:05 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Marc G. Fournier" In-Reply-To: <20060403140902.C947@ganymede.hub.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) 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 Reply-To: Daniel Eischen 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:20:07 -0000 On Mon, 3 Apr 2006, Marc G. Fournier wrote: > On Mon, 3 Apr 2006, Daniel Eischen wrote: > > >> 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 ... I still think ESRCH is correct. The problem isn't that kill isn't seeing other processes; it's that semaphores can be contaminated by different jails. -- DE