From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 13 Sep 2004 - 19:50:57 BST
On Mon, Sep 13, 2004 at 01:33:39PM -0400, Marc E. Fiuczynski wrote:
> Herbert,
>
> >I've already contacted the author, some time ago,
> >and again yesterday, maybe we can work together
> >on that ... we'll see ...
>
> What would you expect to happen via this collaboration
> with the BSDJAIL project? I.e., would vserver move to
> an LSM implementation?
IIRC, several people (including yourself) suggested to
move into the LSM direction, so I assume this would be
a good chance to get some stuff tested there, especially
if this is included into mainline ...
> >yes, it seems to be the IBM approach to vservers
> >(based on LSM but maybe? on it's way into mainline)
>
> It would be good if vserver was based on LSM, too,
> rather than its current approach.
well, really depends on the perspective ...
kernel developers perspective:
- we have a great API, hmm, guess it's calles
LSM, we defined that, and it's perfect ...
- everything else can be implemented either
ontop of that or by modifying and extending
LSM
kernel integrators perspective:
- folks want to use it, we do not want much
work, so let's try to get it into mainline
- it's fine if the user has problems with the
mainline version, it's not ours ...
users perspective:
- linux-vserver is working fine, why do we move
to LSM, which is a) untested, and b) slower?
- aha, because it's more general, and better and
we can add wossname? no thanks, we do not need
that crap ...
> However, as you mentioned in a previous discussion,
> there are additional things that vserver does/requires
> that are not part of LSM.
I guess you've read my paper about linux-vserver
(if not, you can find it on http://linux-vserver.org)
so basically a bunch of issues remain, even if LSM
and CKRM is drastically extended ...
I'm no LSM guy, and I do not have in depth CKRM
knowledge so feel free to correct me about the LSM
and CKRM capabilities ...
* /proc/virtual and /proc/net (context overview)
* unification (immutable but unlinkable hardlinks)
* private namespace support (like chroot++)
* pid virtualization (initpid, fakeinit)
* userspace helper (reboot, context start/stop)
* IP virtualization/mapping 127.0.0.1 and 0.0.0.0
* uts_name virtualization (per context)
* memory virtualization (per context)
* disk limits and context quota (xid tagging)
* pause/unschedule/restart context
* load average and process stats per context
> What are these and which one of those can be assumed
> by CKRM?
* memory accounting and limits?
* socket accounting and limits?
* network accounting and limitations?
* nr processes and fork limitations
* cpu usage and process priority
* file handles, network rates, I/O limits
I consider LSM able to handle the following:
* process isolation, maybe with /proc
* shared memory and ipc isolation
* chroot, maybe even namespaces
* smarter vroot device
* maybe network/socket restrictions??
* maybe devpts and procfs security??
* barrier and maybe iunlink flags ...
HTH,
Herbert
> Marc
>
>
> -----Original Message-----
> From: vserver-bounces_at_list.linux-vserver.org
> [mailto:vserver-bounces_at_list.linux-vserver.org]On Behalf Of Herbert
> Poetzl
> Sent: Monday, September 13, 2004 11:21 AM
> To: Christian Mayrhuber
> Cc: vserver_at_list.linux-vserver.org
> Subject: [Vserver] Re: BSDJAILS in 2.6.x as LSM?
>
>
> On Mon, Sep 13, 2004 at 05:11:09PM +0200, Christian Mayrhuber wrote:
> > What is this?
> >
> > I guess it's incompatible with linux vserver:
> >
> http://kerneltrap.org/node/view/3823?PHPSESSID=547dfb4ca1fb6e90bc185bba02229
> ea5
>
>
>
>
> thanks,
> Herbert
>
> > --
> > lg, Chris
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver