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

Eric W. Biederman ebiederm at xmission.com
Wed Mar 18 17:10:55 PDT 2009


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.


Eric


More information about the Containers mailing list