Re: RFC: Multiple instances of kernel namespaces.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Serge E. Hallyn wrote:
Quoting Hubertus Franke ([email protected]):

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux