On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote:
> * 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...
This was stated already upthread, but sysv IPC is disabled by default
in jails for precisely this reason. So yes, when you turn it on it's
a potential security problem if your jails are supposed to be
compartmentalized.
Kris