From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 17:55:24 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 310FB16A41F; Mon, 3 Apr 2006 17:55:24 +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 D031E43D67; Mon, 3 Apr 2006 17:55:22 +0000 (GMT) (envelope-from scrappy@postgresql.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 07F0F823BF6; Mon, 3 Apr 2006 14:55:13 -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 42478-08; Mon, 3 Apr 2006 14:55:13 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id 9002A823BDF; Mon, 3 Apr 2006 14:55:09 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id EA02F3B82A; Mon, 3 Apr 2006 14:55:10 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id E8A7C3B671; Mon, 3 Apr 2006 14:55:10 -0300 (ADT) Date: Mon, 3 Apr 2006 14:55:10 -0300 (ADT) From: "Marc G. Fournier" X-X-Sender: scrappy@ganymede.hub.org To: Robert Watson In-Reply-To: <20060403182504.S76562@fledge.watson.org> Message-ID: <20060403144916.J947@ganymede.hub.org> References: <20060403140902.C947@ganymede.hub.org> <20060403182504.S76562@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: Daniel Eischen , "Marc G. Fournier" , 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:55:24 -0000 On Mon, 3 Apr 2006, Robert Watson wrote: > > On Mon, 3 Apr 2006, Marc G. Fournier wrote: > >> 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 ... > > The problem here is actually that two postgres instances are trying to use > the same sempahore when they are actually different postgres instances. No, the problem here is that kill(PID, 0) reports that a PID is 'not in use' when, in fact, it is, but in a different jail ... can someone explain to me how 'not hiding that fact' increases information leakage, or causes a security problem? I could see it if I could then proceed to kill that process from a seperate jail, but I don't see what as possible ... For all of the various sysctl's we have for reducing "security due to jails", I think something like that for this instance would be more benign then any of the rest of them :( That is all I'm advocatin / asking for ... some way of reverting kill(PID, 0) back to the old, FreeBSD 4.x behaviour, where this works beautifully :( At least until someone does get around to 'virtualization of SysV IPC' :( > Does PGSQL have a way to specify the semaphore ID to use? Yes, changing the port # that the server responds on ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664