* Tom Lane (tgl@sss.pgh.pa.us) 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
Could this be handled sensibly by using SEM_UNDO? Just a thought.
> 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.
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and starts sniffing or messing with the
semaphores or shared memory segments from other jails? If that's
possible then that's a rather glaring security problem...
Thanks,
Stephen