From: Jonathan Sambrook (jonathan.sambrook_at_dsvr.co.uk)
Date: Thu 03 Apr 2003 - 09:02:56 BST
At 18:11 on Wed 02/04/03, jack_at_solucorp.qc.ca masquerading as 'Jacques Gelinas' wrote:
> 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?
If asking for a _new_ vs with an existing name that has active
processes, my patched new_s_context() returns a failure.
If asking for a _new_ vs with an existing name that doesn't have any
active processes, it reassigns the name to the new context.
> Number are allocated by the kernel, names by administrators.
And the kernel _should_ operate with numbers. No dissent. But that's not
a reason for exporting an implementation detail to userspace.
> A vserver may be given several security context allowing it to start sub-vservers.
Sounds good. I presume you want child vses of different parents to be
able to have the same name? A namespace scheme would handle that.
Implemented by adding a parent field to the linked list structure?
Allow access to a child vs from its ancestors contexts. From ancestors
above its parent you'd have to specify "parent:child",
> Currently, this is not supported (we need a chroot-safe to do that).
Any specs/timescale on 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
There you go. I knew I'd put my foot in it with the utils we're not
> 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.
I was using "chcontext --ctxname name bash" on a development box before
I'd modded our bevs utility (which is equivalent to
"vserver <name> enter").
> 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.
FWIW: Doesn't sound intuitive behaviour to me. If the context isn't
active then I'd expect to _not_ be able to enter it. But maybe that's
just my usage pattern <shrug>.
-- Jonathan Sambrook Software Developer Designer Servers