System update spec proposal

[Mike C. Fletcher]

Christopher Blizzard wrote:
> On Wed, 2007-06-27 at 12:39 -0400, Mike C. Fletcher wrote:
>   
>> Could we get a summary of what the problem is: 
>>     
>
> The main objection to vserver from all the kernel hackers (and those of
> us that have to support them!) is that it's a huge patch 
Okay, so a set of smaller, more targeted patches is preferred.
> that touches
> core kernel bits 
Isn't that going to have to happen in all cases where you can provide 
total isolation of the various elements?  I'd think that adding the 
capability-base control to the major sub-systems would require some 
modifications. Of course, how core and how extensively are probably the 
real issue.
> and it has no plans to make it upstream.
That sounds like a serious problem for maintainability, yes.

Alright, so from my understanding of vserver it sounds like what we want 
is something along these lines:

    * chroot fixes
          o probably the least intrusive and most widely useful part of
            the system is patches to patch a couple of security holes in
            the chroot system (fchdir hole and the mknod hole IIRC)
          o goal of this is to make the chroot perform reliably and
            reasonably securely to provide file-system isolation
          o might be possible to pull just this work out of vserver
    * overlay/COW filesystem
          o goal here is to allow for a tree of overlays with read/only
            read/write support on each layer
          o aufs is the closest project at the moment?
    * hardware access capabilities and rate limiting
          o memory
          o cpu
          o disk io
          o network interfaces

where we would want each of those patches to be as small, maintainable 
and elegant as possible, with all targeted for upstream inclusion.  I'm 
guessing that it's the third set that cause the patch-size to balloon, 
as it seems rather involved.  The first two alone, though, should 
provide quite a lot of the functionality we want and be reasonably 
general in their interest.

So I guess we'd want three kernel hackers (or so) to work on the three 
projects simultaneously.  First is probably a small project.  Second is 
likely just a matter of massaging the code.  Third is an involved 
project that would likely have to be working with SELinux and the like 
to try to integrate everything.

Anyway, that's just the way it sounds to me,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com