From: Rik van Riel (riel_at_surriel.com)
Date: Mon 22 Sep 2003 - 21:29:03 BST
On Mon, 22 Sep 2003, Herbert Poetzl wrote:
> On Mon, Sep 22, 2003 at 02:53:23PM -0400, Rik van Riel wrote:
> > I'm wondering how much of the 2.4 vserver infrastructure
> > is really needed to achieve the same functionality in 2.6.
>
> guess we need some central syscall switch, as proposed
> by yourself, and a nice (working) concept for context
> creation, manipulation and destruction ...
Or we reuse some other security framework's system call
for that, if possible.
The more code is shared between vserver and the other
stuff that's already there, the easier it will be to get
vserver functionality merged.
> > Ideally vserver would be standard functionality and not
> > a separate fork.
>
> agreed, but that is a long way ...
That depends on how big the changes are that vserver
still needs, on top of the other functionality that's
already in 2.6 ...
> > For the various components of vserver, I could envision
> > using these technologies:
> >
> > - unbreakable chroot
> > --> filesystem namespaces, CLONE_NS, recursive bind mount
> > (already in 2.4 and 2.6 kernels, needs userspace helper)
>
> did that some time ago, seemed to work reasonably well,
> (see http://www.13thfloor.at/VServer/Virtual/)
Cool!
However, I'm not sure you would even need kernel patches for
this ;)
> > - separated out /proc namespaces
> > --> cannot be done yet, needs vserver implementation
> > reuse same implementation for selinux ?
>
> maybe separating out some lists will do a major part
> of the /proc virtualization, /proc/mount can be done
> with the namespace virtualization, resources should be
> done by the CKRM, processes will be done by vserver ...
Absolutely. This isn't just a vserver thing, but part of
something bigger.
> > - firewalling, probably IP address binding
> > --> netfilter & selinux framework
>
> I would prefer a virtual network device like that Alex?
> does, so you can create it from outside, and configure
> it from inside ... where iptables & co do the security
> on both sides ...
You're right. It would be better if the root inside the
vserver could do things to protect the vserver from the
outside world.
Virtual network device it is ...
> > - cpu & memory resource use of vservers
> > --> CKRM, see http://ckrm.sourceforge.net/
>
> we'll see ...
> I currently doubt that class and context fit well
Why ?
> > - network resource use of vservers
> > --> reuse normal traffic control infrastructure,
> > maybe selinux infrastructure
> >
> > - per-vserver disk quota
> > --> maybe the selinux people are interested in this too ?
> > make this something generic, beyond just vserver
>
> guess this will not make it into selinux, because the
> per context tagging of files/dirs is a requirement, but
> nobody would do that without good reason.
> same goes for the per context disk limits ...
Even if the selinux people aren't initially interested (I don't
know if they are, I'll have to ask), that doesn't mean we couldn't
hook into the selinux framework.
Remember, if the disk quota stuff is also useful for people who
aren't using vservers, then there's a better chance of getting
help from those other people in implementing and merging things.
> > Having vserver as small as possible should not only make it
> > easier to maintain, but also to get it merged upstream.
>
> good idea ... 8-)
;)
Rik
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan