From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Thu 29 Jan 2004 - 23:08:13 GMT
I like option a; I think that using the LSM framework is the best way to
go, and ensures that you have a whole lot less work in the future ->
instead of patching in a vserver framework, instead you have a more
established API that will be less of a moving target to develop against.
It also makes it more likely to become part of hte mainstream kernel.
I don't see the need to continue with 2.4 development beyond maintenance
mode. If I were you, I'd finish up development of 1.4, and only do
bug/security fixes from there. The current version of vserver on 2.4.x
is working, and that's good enough. If people want the cool new
features, then they can get that in version 2.6.
Also, I have an ulterior motive -> once 2.6 development reaches
something stable, I can switch my distribution over to 2.6, and start
rebuilding everything for the new selinux and vserver. That would make
be very happy.
BTW, on a somewhat related note: Has anyone else here used EVFS (the
encrypted virtual filesystem?) I've made a tiny patch to this for kernel
2.4.23/2.4.24, but the author never got back to me, and seems to have
given up maintenance of it. But, it's the only working, quick
inode-level file encryption system that I know of, and I'm interested in
keeping using it. Anyone with more experience than interested in helping
port it to kernel 2.6? I warn you, the code is a bit messy...
On Thu, 2004-01-29 at 13:25, Herbert Poetzl wrote:
> a) freeze the 2.4 vserver development at some
> point, only do some updating and maintenance,
> and continue with a SE-Linux/LSM version of
> - smaller, less intrusive, linux-vserver
> patches for 2.6.x
> - additional security features provided by
> - userspace configuration of vservers would
> require extensive changes (unification,
> procfs security, ...)
> - different setup/tools between 2.4 and 2.6
Vserver mailing list