Re: Anyone tried the "vserver" patch?

From: Jacques Gelinas (jackat_private)
Date: Mon Dec 10 2001 - 09:47:16 PST

  • Next message: Chris Wright: "[ANNOUNCE] 2001_12_10 patch against 2.4.16"

    On Sat, 8 Dec 2001 15:18:41 -0500, Chris Wright wrote
    > * Jacques Gelinas (jackat_private) wrote:
    > > No. This has been tested. Since 2.4.10, all tests we did failed.
    > cool, thanks for the correction.  i wasn't very clear, and meant
    > chroot(2) can be broken.  the reason is chroot(2) does not change the
    > cwd.  but, vserver is using chroot(1) which includes the proper
    > chdir(2).  sorry for the confusion.
    No this is what I was talking about (the system call). There are two ways to
    break out of a chroot environment. One is to open the device (/dev/hda) and dig
    your way in the file system "by hand". vserver do not have those special files
    and are not allowed to create them.
    the other solution is to slide the carpet under your feet(tm) :-)
    You keep your current directory and do a chroot in a sub-directory. Then your
    current directory is out of scope, compared to the new root. So you are free to
    chdir("..") to the real root.
    Another solution is to open a directory (using open system call), keep the handle
    and perform the chroot. Then you use fchdir() to change to this directory, again
    outside of the new root. So you are free to move to the real root.
    In the vserver source, you will find a file tests/ which test both
    case. The nice thing is that since 2.4.10, all tests failed. I would say that
    chroot(2) is not reversible, whatever you do with your current working directory.
    I strongly believe that chroot has to be that way. This is a simple system call and
    this is what people expect (not breakable). So if you think we have missed a
    way to escape out of a chroot(), please tell me and we will make sure the kernel
    is fixed.
    > > > - i don't like that it touches ext2 and ext3 directly.  this makes it
    > > >   brittle w.r.t. filesystems (something we specifically don't do in LSM).
    > >
    > > No way out if we want to have a workable unification with hard links.
    > yes, i agree.  but unification has the problem of hard links, meaning all
    > vservers have to be in same mount point.  this seems like a limitation
    > to me.  it would be nice if read-only wasn't limited to per-superblock
    > such that you could effectively mount -o ro --bind.  i know you didn't
    > like the granularity limitations of this directory based approach.
    > of course, w/out extended attributes you do have to jump through some
    > hoops to get file level granularity, and i appreciate the simplicity
    > and effectiveness of vserver.
    Another solution would be to use LVM and its snapshot mecanism. Call it "instant
    vservers". I have not tried it though.
    Jacques Gelinas <jackat_private>
    vserver: run general purpose virtual servers on one box, full speed!
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon Dec 10 2001 - 09:47:42 PST