Re: semaphore usage "port based"?

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