From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 17:52:39 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 87B8116A401; Mon, 3 Apr 2006 17:52:39 +0000 (UTC) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 890F643D5C; Mon, 3 Apr 2006 17:52:34 +0000 (GMT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k33HqXKC015175; Mon, 3 Apr 2006 13:52:33 -0400 (EDT) To: Robert Watson In-reply-to: <20060403181621.P76562@fledge.watson.org> References: <20060402163504.T947@ganymede.hub.org> <25422.1144016604@sss.pgh.pa.us> <25526.1144017388@sss.pgh.pa.us> <20060402213921.V947@ganymede.hub.org> <26524.1144026385@sss.pgh.pa.us> <20060402222843.X947@ganymede.hub.org> <26796.1144028094@sss.pgh.pa.us> <20060402225204.U947@ganymede.hub.org> <26985.1144029657@sss.pgh.pa.us> <20060402231232.C947@ganymede.hub.org> <27148.1144030940@sss.pgh.pa.us> <20060402232832.M947@ganymede.hub.org> <20060402234459.Y947@ganymede.hub.org> <27417.1144033691@sss.pgh.pa.us> <20060403164139.D36756@fledge.watson.org> <14654.1144082224@sss.pgh.pa.us> <20060403174043.S76562@fledge.watson.org> <14905.1144084059@sss.pgh.pa.us> <20060403181621.P76562@fledge.watson.org> Comments: In-reply-to Robert Watson message dated "Mon, 03 Apr 2006 18:22:42 +0100" Date: Mon, 03 Apr 2006 13:52:33 -0400 Message-ID: <15174.1144086753@sss.pgh.pa.us> From: Tom Lane Cc: "Marc G. Fournier" , pgsql-hackers@postgresql.org, freebsd-stable@FreeBSD.org, 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:52:39 -0000 Robert Watson writes: > Any multi-instance application that uses unvirtualized System V IPC must know > how to distinguish between those instances. Sure. > How is PostgreSQL deciding what semaphores to use? Can it be instructed to > use non-colliding ones by specifying an alternative argument to pass to > ftok(), or ID to use directly? The problem here is not that we don't know how to avoid a collision. The problem is stemming from code that we added to prevent semaphore leakage during failure recoveries. The code believes that it is deleting a semaphore set left over from a crashed previous instance of the same postmaster. We don't use ftok() to determine the keys, and I'm disinclined to think that doing so would improve the situation: you could still have key collisions, they'd just be unpredictable and there'd be no convenient mechanism for escaping one if you hit it. > However, if applications behave incorrectly when treading over each other > because either they aren't written to support specifying how not to walk over > each other, or if they are not configured to use that support, then they're > not going to behave well :-). Postgres is absolutely designed not to walk all over itself. It is, however, designed to clean up after itself, and I don't consider that a bug. The problem here is that by redefining the behavior of kill, you've prevented the code from detecting the existence of the other postmaster, and thereby triggered the cleanup behavior. I don't exactly see why it's considered such a critical security feature that kill return ESRCH rather than, say, EPERM for processes in another jail. kill won't tell you what that process is or what it's doing, so the amount of information leaked is certainly pretty trivial. It'd be fine if FBSD actually had a jail implementation that leaked zero information, but you don't --- in fact, you're saying it's a feature that you don't. Perhaps a reasonable compromise would be to have the SysV-IPC-allowed-in-jails switch also restore the normal return value of kill(). This seems sensible to me because the GETPID feature makes PIDs be part of the API that is exposed across jails. regards, tom lane