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

[Eric W. Biederman]

Mike Waychison <mikew at google.com> writes:

> Eric W. Biederman wrote:
>> Mike Waychison <mikew at google.com> writes:
>>
>>> Cedric Le Goater wrote:
>>>> Dan Smith wrote:
>>>>> SH> (Note that in Dan's next version, he did move unshare into
>>>>> SH> userspace)
>>>>>
>>>>> The idealist in me still wants it to be in the kernel.  However, after
>>>>> seeing it done I agree that it's the right thing to do, at least in
>>>>> this case.
>>>> I would say in all cases.
>>>>
>>>> as you can't unshare(CLONE_NEWPID), 
>>> Eric,
>>>
>>> Is there a particular reason the above doesn't work?  I made an attempt to
>>> implement it a while back, but haven't convinced myself that signals and
>>> re-attaching a new struct pid to a running task is correct.
>>
>> Last time I was thinking about this I figured unsharing a pid namespace would
>> simply place it's children in a different pid namespace, not the originating
>> process.
>>
>> Would that semantic be useful?  It would certainly be a lot less effort than
>> changing the pid on a running process correctly.
>
> Hmm, that would be a little odd.  I think getting the unsharing task to become
> pid 1 is a bit easier to understand and it makes it clear which task is the
> reaper for the new namespace.  Otherwise the first child becomes pid 1 but it
> isn't the reaper.

For very lightweight pid namespaces that may be desirable, and that is where
all of this conversation originally started.   I am happy to set the starting
pid to 2 to avoid confusion on that point.

One of the other problems with changing the pid is that user space in general
glibc in particular can not cope with the pid of a process changing.

My memories are foggy at the moment but I do know that on the several occasions
we have looked at unshare of the pid namespace it has failed due to kernel issues.
I also remember I was close to having resolved the issues of unsharing the pid
namespace if we did not change the pid of processing calling unshare.


You did not answer my question.  I don't quite see how you were envisioning
using unsharing the pid namespace as part of restart so I can't tell if my
proposed semantics would work for that case.

Eric