[lkml]   [2006]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: Multiple instances of kernel namespaces.
"Serge E. Hallyn" <> writes:

> Quoting Eric W. Biederman (
>> At this point I have to confess I have been working on something
>> similar, to IBM's pid virtualization work. But I have what is at
>> least for me a unifying concept, that makes things easier to think
>> about.
>> The idea is to think about things in terms of namespaces. Currently
>> in the kernel we have the fs/mount namespace already implemented.
>> Partly this helps on what the interface for creating a new namespace
>> instance should be. 'clone(CLONE_NEW<NAMESPACE_TYPE>)', and how
>> it should be managed from the kernel data structures.
>> Partly thinking of things as namespaces helps me scope the problem.
>> Does this sound like a sane approach?
> And a bonus of this is that for security and vserver-type applications,
> the CLONE_NEWPID and CLONE_NEWFS will often happen at the same time.
> How do you (or do you?) address naming namespaces? This would be
> necessary for transitioning into an existing namespace, performing
> actions on existing namespaces (i.e. checkpoint, migrate to another
> machine, enter the namespace and kill pid 521), and would just be
> useful for accounting purposes, i.e. how else do you have a
> "ps --all-namespaces" specify a process' namespace?

So I address naming indirectly. The last thing I want to have
is to add yet another namespace to the kernel for naming namespaces.
We have enough namespaces already.

In any sane context for a pid-namespace we need a pid that
we can call waitpid on, so we don't break the process tree.
Which means at least the init process has 2 pids, one
that it's parent sees, and another (1) that it and it's
children see.

So I name pidspaces like we do sessions of process groups
and sessions by the pid of the leader.

So in the simple case I have names like:

> Doubt we want to add an argument to clone(), so do we just add a new
> proc, sysfs, or syscall for setting a pid-namespace name?

That shouldn't be necessary.

> Do we need a new syscall for transitioning into an existing namespace?

That is a good question. The FS namespaces that we already have
has much the same problem. A completely different solution to
this problem seems to have been implemented but I don't grasp it

Inherently transitioning to an existing namespace is something
that is straight forward to implement, so it is worth thinking

If I want a guest that can keep secrets from the host sysadmin I don't
want transitioning into a guest namespace to come too easily.

Currently I can always just create an extra child of pid 1
that I will be my slave. The problem is that this is an extra
process laying around.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-21 11:07    [W:0.128 / U:14.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site