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
S_CAPS="!CAP_SYS_CHROOT"
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!
http://www.solucorp.qc.ca/miscprj/s_context.hc