Eric W. Biederman wrote:
There have been several discussions in the past month about how
to do a good job of implementing a subset of user space that
looks like it has the system to itself. Essentially making
chroot everything it could be. This is my take on what
the implementation of a pid namespace should look like.
Eric, this looks very good. The pspace internal implementation
is very similar to what I was working on objectifying the pidmap
etc. I was pursuing the same route in using find_pid()
functions as the means to distinguish pspaces rather then
actually virtualizing them.
But this code already goes so much further in many many aspects.
Kudos to you.
I am still going through some of the details, but this is an
excellent starting position.
What follows is a real patch set that is sufficiently complete
to be used and useful in it's own right. There are a few areas
of the kernel where the patchset does not reach, mostly these
cause the compile to fail. In addition a good thorough review
still needs to be done. This patchset does paint a picture
of how I think things should look.
From the kernel community at large I am asking:
Does the code look generally sane?
Yes, but I have one question for you...
Large parts of the patch are adding the pspace argument
to find_task_by_pid() and in many cases that argument is
current->pspace.
It might bring down the size of the patch if you
have
find_task_by_pid( pid ) { return find_task_pidspace_by_pid ( current->pspace, pid ); }
and then only deal with the exceptional cases using find_task_pidspace_by_pid
when the pidspace is different..
Does the use of clone to create a new namespace instance look
like the sane approach?
At he surface it looks OK .. how does this work in a multi-threaded
process which does cloen ( CLONE_NPSPACE ) ?
We discussed at some point that exec is the right place to do it,
but what I get is that because this is the container_init task
we are OK !
A bit clarification would help here ...
Hopefully this code is sufficiently comprehensible to allow a good
discussion to come out of this.
Yes
Thanks for your time,
Eric
-- Hubertus
-
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]
