On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote: > * Tom Lane ([EMAIL PROTECTED]) 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
pgpP7JxlYtaUQ.pgp
Description: PGP signature
