[Devel] Re: [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.

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list