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

[Mike Waychison]

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.