[PATCH] [RFC] c/r: Add UTS support

Oren Laadan orenl at cs.columbia.edu
Fri Mar 20 13:53:42 PDT 2009

Mike Waychison wrote:
> Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>>> Ok.  I see what you are trying to accomplish with this and honestly I
>>> think it is silly.
>>> We should start the threads we need in the kernel, and if we need to
>>> run clone_pid fine.  I am not comfortable exporting clone_with_pid to
>>> user space.
>> Even if we create the task tree in userspace, I don't see why we
>> can't have the parent of each nested pid_ns pass CLONE_NEWPID to
>> clone_with_pid() instead of doing clone first and then unsharing
>> the pidns?
>> As for clone_with_pid(), I don't particularly like the semantics,
>> but as was discussed over IRC, we could have clone_with_pid()
>> return -EINVAL unless it is called while it is called from a task
>> inside a restarting container.  (and -EPERM if setting a pid in
>> a pid_ns which was not created as part of the container)  Eric
>> do you dislike that any less?
> Wouldn't this mean the kernel would have to track which namespaces are 
> part of a restart and which aren't?   Seems a little kludgy to me.

We are talking only about pidns, right ?

So we need to keep track of a single pidns - the top level for the
restarting container; that's the container init. We can, e.g., mark
it with a flag.

We can then follow the hierarchy up through pidns until we reach
the one marked, or the topmost, and grant (or deny) permission.


More information about the Containers mailing list