As you might know, the default chroot implementation in Linux is not secure, there are well known ways to break out of a chroot. As the vservers reside in directories below the host system's root, we need a way to make sure that they cannot break out of their area, i.e. that they can't reach the host's or other vservers' areas. To achieve this, linux-vserver uses a marking known as the barrier.
See also Namespaces.
really depends on the version, but basically it ensures that the vserver guest root can not pass a certain 'marked' directory with chroot().
the barrier either consists of a combination of certain attributes (i.e. flags and modes) or of a special flag, which is protected against modification from inside a vserver.
if you need more details, visit #vserver on OFTC and ask ...
Depends on which version of linux-vserver you're using.
<vserver-base-directory> is the directory in which the actual roots of your vservers are
but for mounting/namespace/whatever reasons, it's better to specify it indirectly via <path-to-vserver>/..
chmod 0000 <vserver-base-directory> chattr +t <vserver-base-directory>
Warning for 1.26(1.25): The +t attribute is inherited and you won't be able to modify files and directories that have this flag set. Recent version ot util-vserver care about this, but older ones simply do not know about this and you'll have to remove the flag yourself.
the unwanted inheritance was fixed in the kernel patch
the barrier security was lowered to allow for sequences like:
cd /tmp; mkdir foo; mkdir foo/bar chmod 0000 foo; chmod 0000 foo/bar
so make sure that the barrier conditions (i.e. chmod 000 and chattr +t) are met.
similar to 1.9.x ...
the barrier has become a separate flag, which can be set with recent tools
setattr --barrier <vserver-base-directory>