Re: semaphore usage "port based"? - Mailing list pgsql-hackers

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