Date: Mon, 3 Apr 2006 18:22:42 +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: <20060403181621.P76562@fledge.watson.org> In-Reply-To: <14905.1144084059@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>
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: >> Maybe I've misunderstood the problem here -- is the use of the GETPID >> operation occuring within a coordinated set of server processes, or does it >> also occur between client and server processes? I think it's quite reasonable >> to argue that a coordinated set of server processes should be able to see each >> other, especially if they're running as the same user, in the same jail, >> started at the same time. > > We use the semaphore sets only within postgres server processes; we could > hardly expect client processes to be able to get at them, since in general > clients aren't on the same machine. The issue here, though, is that Marc is > trying to start multiple postgres servers in different jails, and in that > context the different postgres servers aren't "coordinated" in any real > sense. We'd prefer that they didn't interact at all, but they are > interacting because the SysV code isn't restricting IPC to occur only within > a jail. > > BTW, Marc, it occurs to me that a workaround for you would be to create a > separate userid for postgres to run under in each jail; then the regular > protection mechanisms would prevent the different postmasters from > interfering with each others' semaphore sets. But I think that workaround > just makes it even clearer that the jail mechanism isn't behaving very > sanely. Any multi-instance application that uses unvirtualized System V IPC must know how to distinguish between those instances. This is true of any potential communication mechanism used by multi-instance applications -- be it a command line argument to specify an alternative configuration file, or a configuration file that specifies alternative ports, working directories, mail spool directories, etc. If you install two instances of sendmail, it requires some configuration to teach them not to step all over each other, and this is not an accident: if they try to use the same mail spools, ports, etc, things will go badly. I can't imagine that PostgreSQL should be any different -- it has to be pointed at what resources to use and how to use them -- some of that will be a property of how it's written, and some how it's configured. Presumably, running multiple instances of PostgreSQL in jails should not be all that different from running multiple instances on any UNIX machine: they must not overlap where shared resources are concerned. 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? >> I would, in general, consider the use of System V IPC across jails (as >> opposed to in a single jail) unsupported, since it's not consistent with >> the security model. > > That'd be fine with me --- the problem here is that we've got unwanted > communication across jails. If, say, the jail ID were considered part of > semaphore keys, we'd be in fine shape. Well, I think it's definitely unwanted communications, but until such time as FreeBSD supports virtualizing the System V IPC name spaces, the fact that you can communicate between jails when System V IPC support is turned on for the jail shouldn't be a surprise, and should in fact be considered a feature. 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 :-). Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403181621.P76562>