Re: RFC: Multiple instances of kernel namespaces.

[Hubertus Franke <frankeh@watson.ibm.com>]

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/