On Mon, Sep 22, 2003 at 04:29:03PM -0400, Rik van Riel wrote: > 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.
if appropriate .. (I have no problem with sharing ;) > 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 ;) I neither needed nor used kernel patches for that, the kernel patches are for creating the virtual contexts ;) > > > - 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. but without the notion of contexts, you'll have nothing to separate on ... > > > - 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 ? because the class concept applies to 'groups' of processes including inheritance, which would fit verry well, but stops at this level, there seems no concept for per context info/actions ... hopefully I'm wrong, and it all works out ... > > > - 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. right! > 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. agreed, but where would you take the context tag info from, if you do not use contexts ... > > > Having vserver as small as possible should not only make it > > > easier to maintain, but also to get it merged upstream. > > > > good idea ... 8-) > > ;) best, Herbert > 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
