From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: For review: pid_namespaces(7) man page Date: Mon, 04 Mar 2013 09:52:19 -0800 Message-ID: <87k3pnhx2k.fsf@xmission.com> References: <1362110504.15531.4@driftwood> <87wqtr3zg5.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: (Michael Kerrisk's message of "Mon, 4 Mar 2013 13:46:57 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: linux-man , Linux Containers , lkml List-Id: containers.vger.kernel.org Ik1pY2hhZWwgS2VycmlzayAobWFuLXBhZ2VzKSIgPG10ay5tYW5wYWdlc0BnbWFpbC5jb20+IHdy aXRlczoKCj4gT24gRnJpLCBNYXIgMSwgMjAxMyBhdCA0OjM1IFBNLCBFcmljIFcuIEJpZWRlcm1h biA8ZWJpZWRlcm1AeG1pc3Npb24uY29tPiB3cm90ZToKPj4gIk1pY2hhZWwgS2VycmlzayAobWFu LXBhZ2VzKSIgPG10ay5tYW5wYWdlc0BnbWFpbC5jb20+IHdyaXRlczoKPj4KPj4+IEhpIFJvYiwK Pj4+Cj4+PiBPbiBGcmksIE1hciAxLCAyMDEzIGF0IDU6MDEgQU0sIFJvYiBMYW5kbGV5IDxyb2JA bGFuZGxleS5uZXQ+IHdyb3RlOgo+Pj4+IE9uIDAyLzI4LzIwMTMgMDU6MjQ6MDcgQU0sIE1pY2hh ZWwgS2VycmlzayAobWFuLXBhZ2VzKSB3cm90ZToKPj4+IFsuLi5dCj4+Pgo+Pj4+PiBERVNDUklQ VElPTgo+Pj4+PiAgICAgICAgRm9yIGFuIG92ZXJ2aWV3IG9mIG5hbWVzcGFjZXMsIHNlZSBuYW1l c3BhY2VzKDcpLgo+Pj4+Pgo+Pj4+PiAgICAgICAgUElEICBuYW1lc3BhY2VzICBpc29sYXRlICB0 aGUgIHByb2Nlc3MgSUQgbnVtYmVyIHNwYWNlLCBtZWFuaW5nCj4+Pj4+ICAgICAgICB0aGF0IHBy b2Nlc3NlcyBpbiBkaWZmZXJlbnQgUElEIG5hbWVzcGFjZXMgY2FuICBoYXZlICB0aGUgIHNhbWUK Pj4+Pj4gICAgICAgIFBJRC4KPj4+Pgo+Pj4+Cj4+Pj4gVW0sIHBlcmhhcHMgImRpZmZlcmVudCBw cm9jZXNzZXMiPyBTbGlnaHRseSByZXBldGl0aXZlLCBidXQgdHJ5aW5nIHRvIGF2b2lkCj4+Pj4g dGhlIHBvdGVudGlhbCBtaXNyZWFkaW5nIHRoYXQgImEgcHJvY2Vzc2VzIGNhbiBoYXZlIHRoZSBz YW1lIFBJRCBpbgo+Pj4+IGRpZmZlcmVudCBuYW1lc3BhY2VzIi4gKEEgc2luZ2xlIHByb2Nlc3Mg Y2FuJ3QgYmUgYSBtZW1iZXIgb2YgbW9yZSB0aGFuIG9uZQo+Pj4+IG5hbWVzcGFjZS4gVGhpcyBp cyBub3QgYWJvdXQgc2VsZWN0aXZlIHZpc2liaWxpdHkuKQo+Pj4KPj4+IEknbSBub3Qgc3VyZSB0 aGlzIGNsYXJpZmllcyB0aGluZ3MuLi4KPj4+Cj4+Pj4+IFBJRCBuYW1lc3BhY2VzIGFsbG93IGNv bnRhaW5lcnMgdG8gbWlncmF0ZSB0byBhIG5ldyBob3N0Cj4+Pj4+ICAgICAgICB3aGlsZSB0aGUg cHJvY2Vzc2VzIGluc2lkZSAgdGhlICBjb250YWluZXIgIG1haW50YWluICB0aGUgIHNhbWUKPj4+ Pj4gICAgICAgIFBJRHMuCj4+Pj4KPj4+Pgo+Pj4+IEkgdGhvdWdodCBzdXNwZW5kL3Jlc3VtZSBh IGNvbnRhaW5lciB3YXMgdGhlIHNpbXBsZSBjYXNlLiBNaWdyYXRpb24gdG8gYSBuZXcKPj4+PiBo b3N0IGlzIGJ1aWx0IG9uIHRvcCBvZiB0aGF0LiAoT24gcmVzdW1lIGluIGEgbmV3IGNvbnRhaW5l ciBvbiB0aGUgc2FtZQo+Pj4+IHN5c3RlbSwgaWYgb3RoZXIgc3R1ZmYgaXMgZ29pbmcgb24gaW4g dGhlIHN5c3RlbSBzbyB0aGUgYXZhaWxhYmxlIFBJRHMgaGF2ZQo+Pj4+IHNoaWZ0ZWQuKQo+Pj4K Pj4+IEknbGwgYWRkIHNvbWUgd29yZHMgaGVyZSBvbiBzdXNwZW5kL3Jlc3VtZS4KPj4+Cj4+Pj4+ ICAgICAgICBMaWtld2lzZSwgYSBwcm9jZXNzIGluIGFuIGFuY2VzdG9yIG5hbWVzcGFjZSBjYW7i gJRzdWJqZWN0IHRvIHRoZQo+Pj4+PiAgICAgICAgdXN1YWwgcGVybWlzc2lvbiBjaGVja3MgZGVz Y3JpYmVkIGluICBraWxsKDIp4oCUc2VuZCAgc2lnbmFscyAgdG8KPj4+Pj4gICAgICAgIHRoZSAg ImluaXQiIHByb2Nlc3Mgb2YgYSBjaGlsZCBQSUQgbmFtZXNwYWNlIG9ubHkgaWYgdGhlICJpbml0 Igo+Pj4+PiAgICAgICAgcHJvY2VzcyBoYXMgZXN0YWJsaXNoZWQgYSBoYW5kbGVyIGZvciB0aGF0 IHNpZ25hbC4gIChXaXRoaW4gdGhlCj4+Pj4+ICAgICAgICBoYW5kbGVyLCAgdGhlICBzaWdpbmZv X3Qgc2lfcGlkIGZpZWxkIGRlc2NyaWJlZCBpbiBzaWdhY3Rpb24oMikKPj4+Pj4gICAgICAgIHdp bGwgYmUgemVyby4pICBTSUdLSUxMIG9yIFNJR1NUT1AgYXJlICB0cmVhdGVkICBleGNlcHRpb25h bGx5Ogo+Pj4+PiAgICAgICAgdGhlc2Ugc2lnbmFscyBhcmUgZm9yY2libHkgZGVsaXZlcmVkIHdo ZW4gc2VudCBmcm9tIGFuIGFuY2VzdG9yCj4+Pj4+ICAgICAgICBQSUQgbmFtZXNwYWNlLiAgTmVp dGhlciBvZiB0aGVzZSBzaWduYWxzIGNhbiBiZSBjYXVnaHQgIGJ5ICB0aGUKPj4+Pj4gICAgICAg ICJpbml0IiBwcm9jZXNzLCBhbmQgc28gd2lsbCByZXN1bHQgaW4gdGhlIHVzdWFsIGFjdGlvbnMg YXNzb2Np4oCQCj4+Pj4+ICAgICAgICBhdGVkIHdpdGggdGhvc2Ugc2lnbmFscyAocmVzcGVjdGl2 ZWx5LCB0ZXJtaW5hdGluZyBhbmQgc3RvcHBpbmcKPj4+Pj4gICAgICAgIHRoZSBwcm9jZXNzKS4K Pj4+Pgo+Pj4+Cj4+Pj4gSWYgU0lHS0lMTCB0byBpbml0IGlzIHByb3BvZ2F0ZWQgdG8gYWxsIHRo ZSBjaGlsZHJlbiBvZiBpbml0LCBpcyBTSUdTVE9QCj4+Pj4gYWxzbyBwcm9wb2dhdGVkIHRvIGFs bCB0aGUgY2hpbGRyZW4/IChJLkUuIHdpbGwgU0lHU1RPUCB0byBjb250YWluZXIncyBpbml0Cj4+ Pj4gc3VzcGVuZCB0aGUgd2hvbGUgY29udGFpbmVyLCBhbmQgd2lsbCBTSUdDT05UIHJlc3VtZSB0 aGUgd2hvbGUgY29udGFpbmVyPyBJZgo+Pj4+IHRoZSBsYXR0ZXIsIHdpbGwgaXQgb25seSByZXN1 bWUgcHJvY2Vzc2VzIHRoYXQgd2VyZW4ndCBwcmV2aW91c2x5IHN0b3BwZWQ/Cj4+Pj4gOikKPj4+ Cj4+PiBDb3ZlcmVkIGJ5IEVyaWMuCj4+Pgo+Pj4+PiAgICAgICAgVG8gcHV0IHRoaW5ncyBhbm90 aGVyIHdheTogYSBwcm9jZXNzJ3MgUElEIG5hbWVzcGFjZSBtZW1iZXJzaGlwCj4+Pj4+ICAgICAg ICBpcyBkZXRlcm1pbmVkIHdoZW4gdGhlIHByb2Nlc3MgaXMgY3JlYXRlZCBhbmQgY2Fubm90IGJl IGNoYW5nZWQKPj4+Pj4gICAgICAgIHRoZXJlYWZ0ZXIuICBBbW9uZyBvdGhlciB0aGluZ3MsIHRo aXMgbWVhbnMgdGhhdCAgdGhlICBwYXJlbnRhbAo+Pj4+PiAgICAgICAgcmVsYXRpb25zaGlwIGJl dHdlZW4gcHJvY2Vzc2VzIG1pcnJvcnMgdGhlIHBhcmVudGFsIGJldHdlZW4gUElECj4+Pj4KPj4+ Pgo+Pj4+IG1pcnJvcnMgdGhlIHJlbGF0aW9uc2hpcAo+Pj4KPj4+IFRoYW5rcy4KPj4+Cj4+Pj4+ ICAgICAgICBuYW1lc3BhY2VzOiB0aGUgcGFyZW50IG9mIGEgIHByb2Nlc3MgIGlzICBlaXRoZXIg IGluICB0aGUgIHNhbWUKPj4+Pj4gICAgICAgIG5hbWVzcGFjZSBvciByZXNpZGVzIGluIHRoZSBp bW1lZGlhdGUgcGFyZW50IFBJRCBuYW1lc3BhY2UuCj4+Pj4+Cj4+Pj4+ICAgICAgICBFdmVyeSAg dGhyZWFkICBpbiAgYSBwcm9jZXNzIG11c3QgYmUgaW4gdGhlIHNhbWUgUElEIG5hbWVzcGFjZS4K Pj4+Pj4gICAgICAgIEZvciB0aGlzIHJlYXNvbiwgdGhlIHR3byBmb2xsb3dpbmcgY2FsbCBzZXF1 ZW5jZXMgd2lsbCBmYWlsOgo+Pj4+Pgo+Pj4+PiAgICAgICAgICAgIHVuc2hhcmUoQ0xPTkVfTkVX UElEKTsKPj4+Pj4gICAgICAgICAgICBjbG9uZSguLi4sIENMT05FX1ZNLCAuLi4pOyAgICAvKiBG YWlscyAqLwo+Pj4+Pgo+Pj4+PiAgICAgICAgICAgIHNldG5zKGZkLCBDTE9ORV9ORVdQSUQpOwo+ Pj4+PiAgICAgICAgICAgIGNsb25lKC4uLiwgQ0xPTkVfVk0sIC4uLik7ICAgIC8qIEZhaWxzICov Cj4+Pj4KPj4+Pgo+Pj4+IFRoZXkgZmFpbCB3aXRoIC1FVU5ET0NVTUVOVEVECj4+Pgo+Pj4gQWRk ZWQgRUlOVkFMLCBhcyBwZXIgRXJpYydzIHJlcGx5LiAoRXJpYyBkb2VzIHRoYXQgZXJyb3IgYWxz byBhcHBseQo+Pj4gZm9yIHRoZSB0d28gbmV3IGNhc2VzIHlvdSBhZGRlZD8pLgo+Pj4KPj4+Pj4g ICAgICAgIEJlY2F1c2UgdGhlIGFib3ZlIHVuc2hhcmUoMikgYW5kIHNldG5zKDIpIGNhbGxzIG9u bHkgY2hhbmdlIHRoZQo+Pj4+PiAgICAgICAgUElEICBuYW1lc3BhY2UgIGZvciBjcmVhdGVkIGNo aWxkcmVuLCB0aGUgY2xvbmUoMikgY2FsbHMgbmVjZXPigJAKPj4+Pj4gICAgICAgIHNhcmlseSBw dXQgdGhlIG5ldyB0aHJlYWQgaW4gYSBkaWZmZXJlbnQgUElEIG5hbWVzcGFjZSBmcm9tIHRoZQo+ Pj4+PiAgICAgICAgY2FsbGluZyB0aHJlYWQuCj4+Pj4KPj4+Pgo+Pj4+IFVtLCBubyB0aGV5IGRv bid0LiBUaGV5IGZhaWwuIFRoYXQncyB0aGUgcG9pbnQuCj4+Pgo+Pj4gKEdvb2QgY2F0Y2guKQo+ Pj4KPj4+PiBUaGV5IF93b3VsZF8gcHV0IHRoZSBuZXcKPj4+PiB0aHJlYWQgaW4gYSBkaWZmZXJl bnQgUElEIG5hbWVzcGFjZSwgd2hpY2ggYnJlYWtzIHRoZSBkZWZpbml0aW9uIG9mIHRocmVhZHMu Cj4+Pj4KPj4+PiBIb3cgYWJvdXQ6Cj4+Pj4KPj4+PiBUaGUgYWJvdmUgdW5zaGFyZSgyKSBhbmQg c2V0bnMoMikgY2FsbHMgY2hhbmdlIHRoZSBQSUQgbmFtZXNwYWNlIG9mCj4+Pj4gY2hpbGRyZW4g Y3JlYXRlZCBieSBzdWJzZXF1ZW50IGNsb25lKDIpIGNhbGxzLCB3aGljaCBpcyBpbmNvbXBhdGli bGUKPj4+PiB3aXRoIENMT05FX1ZNLgo+Pj4KPj4+IEkgZGVjaWRlZCBvbjoKPj4+Cj4+PiAgICAg ICAgVGhlICBwb2ludCAgaGVyZSBpcyB0aGF0IHVuc2hhcmUoMikgYW5kIHNldG5zKDIpIGNoYW5n ZSB0aGUgUElECj4+PiAgICAgICAgbmFtZXNwYWNlIGZvciBjcmVhdGVkIGNoaWxkcmVuIGJ1dCBu b3QgZm9yIHRoZSBjYWxsaW5nIHByb2Nlc3MsCj4+PiAgICAgICAgd2hpbGUgIGNsb25lKDIpIENM T05FX1ZNIHNwZWNpZmllcyB0aGUgY3JlYXRpb24gb2YgYSBuZXcgdGhyZWFkCj4+PiAgICAgICAg aW4gdGhlIHNhbWUgcHJvY2Vzcy4KPj4KPj4gQ2FuIHdlIG1ha2UgdGhhdCAiZm9yIGFsbCBuZXcg dGFza3MgY3JlYXRlZCIgaW5zdGVhZCBvZiAiY3JlYXRlZAo+PiBjaGlsZHJlbiIKPj4KPj4gT3Ro ZXdpc2Ugc29tZW9uZSBtaWdodCBleHBlY3QgQ0xPTkVfVEhSRUFEIHdvdWxkIHdvcmsgYXMgeW91 Cj4+IENMT05FX1RIUkVBRCBjcmVhdGVzIGEgdGhyZWFkIGFuZCBub3QgYSBjaGlsZC4uLgo+Cj4g VGhlIHRlcm0gInRhc2siIGlzIGtlcm5lbC1zcGFjZSB0YWxrIHRoYXQgcmFyZWx5IGFwcGVhcnMg aW4gbWFuIHBhZ2VzLAo+IHNvIEkgYW0gcmVsdWN0YW50IHRvIHVzZSBpdC4KCldpdGggcmVzcGVj dCB0byBjbG9uZSBhbmQgaW4gdGhpcyBjYXNlIEkgYW0gbm90IGNlcnRhaW4gd2UgY2FuIHByb3Bl cmx5CmRlc2NyaWJlIHdoYXQgaGFwcGVucyB3aXRob3V0IHRhbGtpbmcgYWJvdXQgdGFza3MuICBC dXQgaXQgaXMgd29ydGgKYSB0cnkuCgoKPiBIb3cgYWJvdXQgdGhpczoKPgo+ICAgICAgICBUaGUg IHBvaW50ICBoZXJlIGlzIHRoYXQgdW5zaGFyZSgyKSBhbmQgc2V0bnMoMikgY2hhbmdlIHRoZSBQ SUQKPiAgICAgICAgbmFtZXNwYWNlIGZvciBwcm9jZXNzZXMgc3Vic2VxdWVudGx5IGNyZWF0ZWQg YnkgdGhlIGNhbGxlciwgYnV0Cj4gICAgICAgIG5vdCAgZm9yIHRoZSBjYWxsaW5nIHByb2Nlc3Ms IHdoaWxlIGNsb25lKDIpIENMT05FX1ZNIHNwZWNpZmllcwo+ICAgICAgICB0aGUgY3JlYXRpb24g b2YgYSBuZXcgdGhyZWFkIGluIHRoZSBzYW1lIHByb2Nlc3MuCgpIbW0uICBIb3cgYWJvdXQgdGhp cy4KCiAgICAgICAgIFRoZSBwb2ludCBoZXJlIGlzIHRoYXQgdW5zaGFyZSgyKSBhbmQgc2V0bnMo MikgY2hhbmdlIHRoZSBQSUQKICAgICAgICAgbmFtZXNwYWNlIHRoYXQgd2lsbCBiZSB1c2VkIGJ5 IGluIGFsbCBzdWJzZXF1ZW50IGNhbGxzIHRvIGNsb25lCiAgICAgICAgIGFuZCBmb3JrIGJ5IHRo ZSBjYWxsZXIsIGJ1dCBub3QgZm9yIHRoZSBjYWxsaW5nIHByb2Nlc3MsIGFuZAogICAgICAgICB0 aGF0IGFsbCB0aHJlYWRzIGluIGEgcHJvY2VzcyBtdXN0IHNoYXJlIHRoZSBzYW1lIFBJRAogICAg ICAgICBuYW1lc3BhY2UuICBXaGljaCBtYWtlcyBhIHN1YnNlcXVlbnQgY2xvbmUoMikgQ0xPTkVf Vk0KICAgICAgICAgc3BlY2lmeSB0aGUgY3JlYXRpb24gb2YgYSBuZXcgdGhyZWFkIGluIHRoZSBh IGRpZmZlcmVudCBQSUQKICAgICAgICAgbmFtZXNwYWNlIGJ1dCBpbiB0aGUgc2FtZSBwcm9jZXNz IHdoaWNoIGlzIGltcG9zc2libGUuCgpFcmljCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCkNvbnRhaW5lcnMgbWFpbGluZyBsaXN0CkNvbnRhaW5lcnNAbGlz dHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3Jn L21haWxtYW4vbGlzdGluZm8vY29udGFpbmVycw== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758719Ab3CDRwa (ORCPT ); Mon, 4 Mar 2013 12:52:30 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:49545 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758173Ab3CDRw3 convert rfc822-to-8bit (ORCPT ); Mon, 4 Mar 2013 12:52:29 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: mtk.manpages@gmail.com Cc: Rob Landley , linux-man , Linux Containers , lkml References: <1362110504.15531.4@driftwood> <87wqtr3zg5.fsf@xmission.com> Date: Mon, 04 Mar 2013 09:52:19 -0800 In-Reply-To: (Michael Kerrisk's message of "Mon, 4 Mar 2013 13:46:57 +0100") Message-ID: <87k3pnhx2k.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-AID: U2FsdGVkX196r7lK9U3zu5FVcdpSeeQBmdf8ep4hmbc= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% * [score: 0.3847] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.5 XM_Body_Dirty_Words Contains a dirty word * 0.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;mtk.manpages@gmail.com X-Spam-Relay-Country: Subject: Re: For review: pid_namespaces(7) man page X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Michael Kerrisk (man-pages)" writes: > On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" writes: >> >>> Hi Rob, >>> >>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley wrote: >>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote: >>> [...] >>> >>>>> DESCRIPTION >>>>> For an overview of namespaces, see namespaces(7). >>>>> >>>>> PID namespaces isolate the process ID number space, meaning >>>>> that processes in different PID namespaces can have the same >>>>> PID. >>>> >>>> >>>> Um, perhaps "different processes"? Slightly repetitive, but trying to avoid >>>> the potential misreading that "a processes can have the same PID in >>>> different namespaces". (A single process can't be a member of more than one >>>> namespace. This is not about selective visibility.) >>> >>> I'm not sure this clarifies things... >>> >>>>> PID namespaces allow containers to migrate to a new host >>>>> while the processes inside the container maintain the same >>>>> PIDs. >>>> >>>> >>>> I thought suspend/resume a container was the simple case. Migration to a new >>>> host is built on top of that. (On resume in a new container on the same >>>> system, if other stuff is going on in the system so the available PIDs have >>>> shifted.) >>> >>> I'll add some words here on suspend/resume. >>> >>>>> Likewise, a process in an ancestor namespace can—subject to the >>>>> usual permission checks described in kill(2)—send signals to >>>>> the "init" process of a child PID namespace only if the "init" >>>>> process has established a handler for that signal. (Within the >>>>> handler, the siginfo_t si_pid field described in sigaction(2) >>>>> will be zero.) SIGKILL or SIGSTOP are treated exceptionally: >>>>> these signals are forcibly delivered when sent from an ancestor >>>>> PID namespace. Neither of these signals can be caught by the >>>>> "init" process, and so will result in the usual actions associ‐ >>>>> ated with those signals (respectively, terminating and stopping >>>>> the process). >>>> >>>> >>>> If SIGKILL to init is propogated to all the children of init, is SIGSTOP >>>> also propogated to all the children? (I.E. will SIGSTOP to container's init >>>> suspend the whole container, and will SIGCONT resume the whole container? If >>>> the latter, will it only resume processes that weren't previously stopped? >>>> :) >>> >>> Covered by Eric. >>> >>>>> To put things another way: a process's PID namespace membership >>>>> is determined when the process is created and cannot be changed >>>>> thereafter. Among other things, this means that the parental >>>>> relationship between processes mirrors the parental between PID >>>> >>>> >>>> mirrors the relationship >>> >>> Thanks. >>> >>>>> namespaces: the parent of a process is either in the same >>>>> namespace or resides in the immediate parent PID namespace. >>>>> >>>>> Every thread in a process must be in the same PID namespace. >>>>> For this reason, the two following call sequences will fail: >>>>> >>>>> unshare(CLONE_NEWPID); >>>>> clone(..., CLONE_VM, ...); /* Fails */ >>>>> >>>>> setns(fd, CLONE_NEWPID); >>>>> clone(..., CLONE_VM, ...); /* Fails */ >>>> >>>> >>>> They fail with -EUNDOCUMENTED >>> >>> Added EINVAL, as per Eric's reply. (Eric does that error also apply >>> for the two new cases you added?). >>> >>>>> Because the above unshare(2) and setns(2) calls only change the >>>>> PID namespace for created children, the clone(2) calls neces‐ >>>>> sarily put the new thread in a different PID namespace from the >>>>> calling thread. >>>> >>>> >>>> Um, no they don't. They fail. That's the point. >>> >>> (Good catch.) >>> >>>> They _would_ put the new >>>> thread in a different PID namespace, which breaks the definition of threads. >>>> >>>> How about: >>>> >>>> The above unshare(2) and setns(2) calls change the PID namespace of >>>> children created by subsequent clone(2) calls, which is incompatible >>>> with CLONE_VM. >>> >>> I decided on: >>> >>> The point here is that unshare(2) and setns(2) change the PID >>> namespace for created children but not for the calling process, >>> while clone(2) CLONE_VM specifies the creation of a new thread >>> in the same process. >> >> Can we make that "for all new tasks created" instead of "created >> children" >> >> Othewise someone might expect CLONE_THREAD would work as you >> CLONE_THREAD creates a thread and not a child... > > The term "task" is kernel-space talk that rarely appears in man pages, > so I am reluctant to use it. With respect to clone and in this case I am not certain we can properly describe what happens without talking about tasks. But it is worth a try. > How about this: > > The point here is that unshare(2) and setns(2) change the PID > namespace for processes subsequently created by the caller, but > not for the calling process, while clone(2) CLONE_VM specifies > the creation of a new thread in the same process. Hmm. How about this. The point here is that unshare(2) and setns(2) change the PID namespace that will be used by in all subsequent calls to clone and fork by the caller, but not for the calling process, and that all threads in a process must share the same PID namespace. Which makes a subsequent clone(2) CLONE_VM specify the creation of a new thread in the a different PID namespace but in the same process which is impossible. Eric