Date: Mon, 3 Apr 2006 23:25:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tom Lane <tgl@sss.pgh.pa.us> 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: <20060403231143.O76562@fledge.watson.org> In-Reply-To: <15174.1144086753@sss.pgh.pa.us> 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> <15174.1144086753@sss.pgh.pa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Tom Lane wrote: > 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. I guess what I'm saying is this: by turning on system V IPC in a jail, administrators accept that they are using an unsupported configuration, in which the security features of jail, which include hiding the process state of other jails, are known to conflict with the System V IPC services. We specifically disable System V IPC in jails because it is known to have undesirable properties. When configuring systems in that state, the responsibility falls on the administrator to disambiguate the configuration by specifying which resources must be used in order to prevent a conflict, because software operating in that environment will not be able to do so properly. The goal of the switch to enable System V IPC is to allow IPC to be enabled for a single jail at a time, where it can be used to its full capabilities, without violating the security model. If it is turned on for more than one jail, then isolation is not provided for System V IPC. So my recommendation is, if people want to run Postgres in more than one jail at a time, they be provided with a configuration option to disambiguate which semaphore to use: they must hard-code that it will not use the same sempahore already in use by another Postgres instance in another Jail. This is no different than specifying that if there are multiple Apache's running on a single system, that they run on different port/IP combinations. If they aren't configured to do so, one of them will encounter an error when running, because the resource is already in use, and you may get unpredictable results if the two Apaches are started at the same time, restarted, etc, as they will race to acquire the resource. Whether you pull the resource ID out of a hat, use ftok(), or whatever, I really mind, and have no strong opinion. The name space of System V IPC is one of the known problems with the IPC model, and sadly, one accepts those problems by using those IPC mechanisms. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403231143.O76562>