From owner-freebsd-stable@FreeBSD.ORG Tue Apr 4 00:07:28 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 E4B5B16A41F; Tue, 4 Apr 2006 00:07:27 +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 B9CF943D70; Tue, 4 Apr 2006 00:07: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 8D53F823A78; Mon, 3 Apr 2006 21:07:17 -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 25876-03; Mon, 3 Apr 2006 21:07:20 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id 41116823A73; Mon, 3 Apr 2006 21:07:15 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id A47C83D5DB; Mon, 3 Apr 2006 21:07:23 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id A35D73632A; Mon, 3 Apr 2006 21:07:23 -0300 (ADT) Date: Mon, 3 Apr 2006 21:07:23 -0300 (ADT) From: "Marc G. Fournier" X-X-Sender: scrappy@ganymede.hub.org To: Robert Watson In-Reply-To: <20060403230850.P76562@fledge.watson.org> Message-ID: <20060403205630.N947@ganymede.hub.org> References: <20060403140902.C947@ganymede.hub.org> <20060403182504.S76562@fledge.watson.org> <20060403144916.J947@ganymede.hub.org> <20060403230850.P76562@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: Tue, 04 Apr 2006 00:07:28 -0000 On Mon, 3 Apr 2006, Robert Watson wrote: > > On Mon, 3 Apr 2006, Marc G. Fournier wrote: > >>> 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 ... > > So if it's using a different semaphore, why is it finding the semaphore > of another Postgres session and trying to use that? The problem you're > describing is a property of a collision on a semaphore. If there's no > semaphore collision, how would it ever find the pid from another jail? All PostgreSQL processes use "port * 1000" as their starting port for semId ... if "port * 1000" is reported as in use, the first thing that the PostgreSQL process does is kill(PID, 0) the PID returned by semctl(GETPID) to see if, in fact, there is a process running ... if not, PostgreSQL reuses that semaphore, if not, it goes to (port*1000)+1, and tries again ... until it can find a free semaphore that isn't in use ... Now, it doesn't care if PID does exist, but isn't a postgresql process, it will just move on to the next (errors on the side of caution) ... so it doesn't need to know anything, other then that PID is 'in use' ... basically, if the OS reports it as being in use, even if that 'in use' happened to be a 1 second perl script running, we don't care, we just move to the next semId ... So, without kill(PID,0) returning that the process is 'in use', we can't move onto the next semId to find one not in use :( Now, there are two ways around that from a 'non-coding' perspective ... one is to change the port that the PostgreSQL daemon runs on, which is inconvient, since then ppl need ot know to change their applications accordingly ... the other is to setup the pgsql "superuser" in the vServer to be a different uid in each one, so that even if the process is reported as 'not in use', it can't attach to the existing semaphore, since its owned by another user ... slightly inconvient from a 'setup perspective', but at least then its a one time only thing, so I livable solution ... ... and a solution that doesn't require anyone but me to change :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664