Date: Mon, 03 Apr 2006 13:52:33 -0400 From: Tom Lane <tgl@sss.pgh.pa.us> To: Robert Watson <rwatson@FreeBSD.org> Cc: "Marc G. Fournier" <scrappy@postgresql.org>, pgsql-hackers@postgresql.org, freebsd-stable@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: [HACKERS] semaphore usage "port based"? Message-ID: <15174.1144086753@sss.pgh.pa.us> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15174.1144086753>