On Mon, 3 Apr 2006, Stephen Frost wrote:
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 is why it's disabled by default, and the jail documentation specifically
advises of this possibility. Excerpt below.
Robert N M Watson
security.jail.sysvipc_allowed
This MIB entry determines whether or not processes within a jail
have access to System V IPC primitives. In the current jail imple-
mentation, System V primitives share a single namespace across the
host and jail environments, meaning that processes within a jail
would be able to communicate with (and potentially interfere with)
processes outside of the jail, and in other jails. As such, this
functionality is disabled by default, but can be enabled by setting
this MIB entry to 1.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
