At 18:11 on Wed 02/04/03, [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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.
Absolutely.
> > 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",
"grandparent: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>.
Regards,
Jonathan
--
Jonathan Sambrook
Software Developer
Designer Servers
pgp00000.pgp
Description: PGP signature
