lkml.org 
[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Multiple instances of kernel namespaces.
Serge E. Hallyn wrote:
> Quoting Hubertus Franke (frankeh@watson.ibm.com):
>
>>However, question here is whether the container (as we used it) provides
>>the "binding" object for these clones. One question for me then is
>>whether cloning of namespaces is always done in tandem.
>
>
> No.

Thought so..

>
>
>>As you are bringing the migration up, we can only clone fully contained
>
>
> By clone do you actually mean clone(), or did you mean restart from
> checkpoint?

clone_<namespace> , so its neither nor ...
Essentially creating a new namespace ! That's what Eric was suggesting.

>
> If clone, then I don't understand the problem.
>
> If restart from checkpoint/migrate, then I think the answer has to be
> that that is a special case which we have to handle. Note that to clone
> a fs namespace, you need CAP_SYS_ADMIN. We could add another check in
> there to deny CLONE_NEWNS when CLONE_NEWPID is not specified IF and ONLY
> IF we are already no longer in container_id==0. Or even better, when
> a pid-namespace has been designated as migrateable.
>
> Anything other than that would be too limiting. Note that fs namespaces
> are going to be used for multi-level directories, for instance.

That's a reasonable approach. Give the general capability (since C/R + migration
is an additional capability that might not be utilized by many) and leave it to
the sys_admin to specify what is allowed or not
>
>>namespaces ! One could make that a condition of the migration or build
>>it right into the initial structure. Any thoughts on that ?
>
> So in other words I'm saying that this is the admin/user's problem to
> keep straight. Dealing with fs-namespaces in this sense could perhaps be
> dealt with later by hand in checkpoint/migrate/restore code by
> a) at checkpoint:
> i) checking the fs-namespace of each process or thread
> ii) storing /proc/mounts for each fs-namespace
> b) at restore, do CLONE_NEWNS for each process which needs it,
> and using the stored /proc/mounts to rebuild the
> namespace.
>
Something like it .. yes...

> Of course /proc mounts is itself relative to a namespace in the
> case of bind mounts, so I'm actually not sure this is feasible.
>
> -serge
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-20 22:49    [W:0.123 / U:1.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site