From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Thu 03 Apr 2003 - 00:11:00 BST
On Wed, 2 Apr 2003 11:13:01 -0500, Jonathan Sambrook wrote
> At 22:36 on Tue 01/04/03, jack_at_solucorp.qc.ca masquerading as 'Jacques Gelinas' wrote:
> Why put the names into kernelspace when it could be done in userspace?
> new_s_context gains an extra parameter, but are you going to argue that
> new_s_context is a 'nice' interface to start off with :) ?
Indeed, it should be broken in more than one system call. But the argument
is not about prettyness here.
> We _never_ use the number, so, given we're starting from scratch,
> building a larger amount of userspace scaffolding rather than a smaller
> amount of kernelspace code doesn't make sense.
> Overall it's cleaner to have the linked list in the kernel rather than
> have to maintain it in userspace.
> Other than keeping anything which can be outside of the kernel outside
> of the kernel, what is gained by using numbers rather than names
> in userspace?
Uniqness. Number are allocated by the kernel, names by administrators.
A vserver may be given several security context allowing it to start sub-vservers.
Currently, this is not supported (we need a chroot-safe to do that).
Currently, very few utility need to manage that. I agree that other area
in the kernel work by name.
> As an aside:
> On those occasions when you log into the root context on a machine and
> need to enter a vs, it's nice to:
> chcontext --ctxname <name> bash
> rather than have to look up the name->id->.
> (Not that we'd do that since we have the bevs tool, but...)
vserver name enter
is even simpler and secure. chcontext --ctxname name bash is kind of a security
hole. You are executing in the root, but with the security context of a vserver.
it may be possible to cause problem to the root server because
of that For example, while you are in this context, you use some tool to
review a file in /vservers/name/somewhere and this file has been properly
edited to break the tool you are using..
vserver name enter
works even if the vserver is not running. A new security context is allocated.
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!