From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Thu 24 Jan 2002 - 18:46:40 GMT
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 <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!