Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The man page for jail says that allow.sysvipc enables "System V primitives [to] share a single namespace across the host and jail environments..." thus "... processes within a jail would be able to communicate with ... processes outside of the jail, and in other jails."

What are the practical security implications of this? The most extreme interpretation would imply that when using this option, there is little effective security within the entire jail infrastucture. (If processes can interfere with and communicate with other processes on the host and other jails then why bother with the jail at all?)

share|improve this question

So, it turns out that the extreme interpretation is correct. Allowing sysvipc "... defeat[s] the whole purpose of having a jail; privileged users from the jail would be able to affect processes outside the jailed environment."

UPDATE Aug 3, 2010: After some serendipitous research, I've been able to flesh out some details. The problem stems from the fact that process permissions are based on UIDs (note that this means the number, not the string identifier). So, even though the user spaces for the host and jail are mutually separate, this division isn't iron-clad and given that root has a UID of 0, we get the quote above. Some options to minimize the risk:

  1. Ensure all users across the entire system (host and jails) have different UIDs
  2. Disable root login for the jails (won't help with processes run as root so sudo tricks but some is better than none.)
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.