About this list Date view Thread view Subject view Author view Attachment view

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?
> Uniqness.

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
using. Sorry.

> 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..
> Further,
> 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

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 03 Apr 2003 - 09:25:11 BST by hypermail 2.1.3