[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),
> 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
Would that semantic be useful? It would certainly be a lot less effort than
changing the pid on a running process correctly.
More information about the Containers