re: vserver and chroot's

About this list Date view Thread view Subject view Author view Attachment view

From: Jacques Gelinas (
Date: Thu Jan 24 2002 - 13:46:40 EST

On Thu, 24 Jan 2002 13:03:27 -0500, Martin Josefsson wrote
> On Thu, 24 Jan 2002, Jacques Gelinas wrote:

> > > But it doesn't work when run in an vserver, I havn't looked at the code
> > > yet but I assume that CAP_SYS_ADMIN or something similar is needed to be
> > > able to really execute a chroot() call.
> >
> > chroot is controlled by CAP_CHROOT. A little modified escaperoot does work
> > in a vserver (as of kernel ctx-5).
> hmm how does that work?

Sorry it is CAP_SYS_CHROOT. In the chroot system call, if the process
does not have the CAP_SYS_CHROOT capability, the system call aborts.
By default, root has this capability and root in a vserver also has it. If you
put the following line


in your vserver configuration file, no process in the vserver, even own
by root will be able to use the system call.


Oops, chcontext did not support CAP_SYS_CHROOT.I added and this
created a little bug. Removing the capability was preventing the
first chroot (the one setting the vserver) from working.

I have fixed that, so in the next release, you can disable chroot
in a vserver altogether.


the vserver has a nice trick. One process may change its own capability
ceiling and remove the CAP_SYS_CHROOT and then execute some child
program. This program and children won't be able to use chroot anymore.
ftp server could be modified (for example) to benefit from this feature.

> Or you could check the permissions and bail out if they are wrong, I don't
> like the 'chmod 000 /vservers/xx/..', if it's a symlink we could be
> changing permissions of a directory that shouldn't be changed. Complain
> and let the admin work it out.

This is what I did. Thanks!

Jacques Gelinas <>
vserver: run general purpose virtual servers on one box, full speed!

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT