[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automated package testing (Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?)

On Fri, Dec 13, 2002 at 08:48:18AM -0600, John Goerzen wrote:

> On Thu, Dec 12, 2002 at 11:03:58PM -0500, Matt Zimmerman wrote:
> > On Fri, Dec 13, 2002 at 09:53:02AM +1100, Brian May wrote:
> > 
> > I have the beginnings of a UML-based tool for this kind of testing.  Since
> > it's a complete kernel+userland environment, this makes it possible to test
> > things like network daemons which are problematic in a chroot, especially if
> > the same daemon is running on the host.
> I'd also be interested in a vserver-based tool, I think. vserver can provide
> almost all of the same benefits you derive from UML, and yet runs on more
> architectures and doesn't take the performance hit.

I had looked at vserver before, but the description is not very informative and
I got the impression that it only handled the issue of sockets.  I see now that
it also tries to prevent the processes from seeing each other.  I still see
these advantages to UML:

- entirely separate process table with its own working init(1), so full
  system startup and shutdown can be tested, as well as init itself
- shareable, copy-on-write block devices (makes repeated testing much more
- can run unprivileged, which improves security and makes it possible to
  share physical systems without giving out root access (especially useful
  when non-i386 architectures mature)
- separate kernel, which allows for a certain amount of kernel- and
  module-related testing

It also does not require a kernel patch (though the skas patch will improve
performance greatly).

The disadvantages being:

- performance (as you pointed out), though this is not nearly as much of an
  issue with skas
- i386-only, at the moment.  This is not an architectural limitation, only a
  lack of development resources for other platforms.  Some progress has been
  made for powerpc, sparc, ia64 and win32

As a side note, this paragraph in the vserver documentation makes me

> Non reversible isolation
>    Unix and Linux have always had the chroot() system call. This call was
>    used to trap a process into a sub-directory. After the system-call,
>    the process is led to believe that the sub-directory is now the root
>    directory. This system call can't be reversed. In fact, the only thing
>    a process can do is trap itself further and further in the file-system
>    (calling chroot() again).

Unless their kernel patch changes the semantics of chroot() and a bunch of
other things, this is not at all true, and it is trivial to break out of a
chroot given root access.

 - mdz

Reply to: