[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