Date: Mon, 3 Apr 2006 17:49: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: <20060403174043.S76562@fledge.watson.org> In-Reply-To: <14654.1144082224@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Apr 2006, Tom Lane wrote: > That's a fair question, but in the context of the code I believe we are > behaving reasonably. The reason this code exists is to provide some > insurance against leaking semaphores when a postmaster process is terminated > unexpectedly (ye olde often-recommended-against "kill -9 postmaster", for > instance). If the PID returned by GETPID is nonexistent or belongs to a > process not owned by the postgres userid then we assume that the semaphore > set can be recycled. We could get fooled by PID recycling if the PID > returned by GETPID belongs to a postgres-owned process that isn't actually > the original owner, but the penalty is just that we'll fail to recycle > semaphores that could be released. Not very harmful, and not very probable > either, unless you're running postgres under a userid that's used for a lot > of other stuff too. There is not much risk of long-term leakage of many > semaphore sets, even if you've got lots of postmaster crashes going on > (which I sure hope you don't). The code is designed to retry the same > semaphore keys on each cycle of life, so you'd have to get fooled by chance > coincidence of existing PIDs every time over many cycles to have a severe > resource-leakage problem. (BTW, Marc, that's the reason for *not* > randomizing the key selection as you suggested.) > > So I think the code is pretty bulletproof as long as it's in a system that > is behaving per SysV spec. The problem in the current FBSD situation is > that the jail mechanism is exposing semaphore sets across jails, but not > exposing the existence of the owning processes. That behavior is > inconsistent: if process A can affect the state of a sema set that process B > can see, it's surely unreasonable to pretend that A doesn't exist. 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. After all, coordinated server applications frequently use signals to manage resources and perform asynchronous notification (i.e., SIGCHLD, SIGHUP, etc). If we're talking about clients and servers coordinating using the same System V IPC name space, I find myself less sympathetic to the idea that otherwise unrelated processes on either side of the IPC mechanism should be using out-of-band process operations to test for mutual presence. There has been occasional investigation of virtualizing the System V IPC name space, but as you are no doubt aware, the name space doesn't lend itself to virtualization, as it fails to be conveniently hierarchical, etc. This is just another of the ways in which System V IPC offers quite useful IPC services in less useful ways. 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. However, I have doubts about the behavioral dependency we're talking about above. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060403174043.S76562>