From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932129AbcGHFwa (ORCPT ); Fri, 8 Jul 2016 01:52:30 -0400 Received: from mail-db5eur01on0119.outbound.protection.outlook.com ([104.47.2.119]:2981 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751427AbcGHFwU (ORCPT ); Fri, 8 Jul 2016 01:52:20 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Thu, 7 Jul 2016 19:16:18 -0700 From: Andrew Vagin To: James Bottomley CC: , Linux API , Containers , lkml , , "Serge E. Hallyn" Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Message-ID: <20160708021617.GB10512@outlook.office365.com> References: <87r3b7pxja.fsf@x220.int.ebiederm.org> <20160706141348.GB20728@mail.hallyn.com> <20160707133631.GA2994@mail.hallyn.com> <1467903712.2347.16.camel@HansenPartnership.com> <1467919055.2322.36.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline In-Reply-To: <1467919055.2322.36.camel@HansenPartnership.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [67.183.159.197] X-ClientProxiedBy: CY1PR21CA0099.namprd21.prod.outlook.com (10.164.213.25) To DB5PR0801MB1432.eurprd08.prod.outlook.com (10.167.229.20) X-MS-Office365-Filtering-Correlation-Id: 57742a59-b679-433f-74a2-08d3a6d5e342 X-Microsoft-Exchange-Diagnostics: 1;DB5PR0801MB1432;2:tPs1QPRf3IMT7EFJ8gjpemLR6SJmlS4XusoKQE43DrgDK5+V+nqYsvX00gC/QXcfyfL2EJyeQ9r+eDt4o2rHGnRJLFGkmhVCTCGMN+WH12FAE6fx+4H+51mk5KnLVXkAoocZTOLXpLjbrOhWDd9E8wn+wxRehLvr0P670tigMqHgVQkqyO0kutmeFtHI0hN1;3:ovxOJRINck0XqOZpEnYtdD2Dd2yGKMS1AGGHGUEWP42z35zQ2YOBnyhoDArUNyavrDPcgymgL1TjKzD/trZjxKwI0cBZt04IkHRgNsDKZVhbP859upXMtArvpghmsQId X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0801MB1432; X-Microsoft-Exchange-Diagnostics: 1;DB5PR0801MB1432;25:HWnLmfdyzNLytM4ulcAwY34pJS+bbsJavpm7U1gcbVMD9ngbpSvc+80tbfQ9VmP+YycpYtbn1ryJ0ypRPmNJ9RlJ6804Y/t83OBatNFup37D79NiPhrXtCuFsajCykV4ZMfZL0hjvZKBIjBgHoJDHj/UlOZGi1jFIBsrxkaMQfbJGCGn78pL9lr5pHU53Mu/U4gVkGPeghHnTpYRB/IoqS73fKSTgn4KngPM+wmpSguXY5AEz2N/eJuN6MhXEZj1GMgGcaSo7fL3cX/g0mqsLdVqnkQzkxS1LKO3xRDzULxwUV3fr7/izsB94hSsf5exjeqHnZJrlWFmWLhjL2Q9Rsb93qMd+2Kb/w6AO87PSvBBulN9FkbwhE5BJlBNAFTarqpNZZqCBscO+57hJrWllHdR02tuEPriY9YuCBdBgldqU5QbL1pYUvfJ7KoQirIncpGpWWTYLf8QHYkjTUiQnck7Tux2cf7hsTGGXcEvesC/2DvCgFRBxAviJT8PlsUleu52Key8dhqbkVB4AOSGu2C1/2SPqDraSgNLncn37yGuZPgLWF3wGm36DHP8o4xY5X9gT3HWuR0AJYDMX5Ed6s9w/x6twZzie8nzN0OzWxuKp974hlpBSfOzWzGJj/93eHx0gSboy2ZgP7THukJeucWIWK2kZgzoyh4QnH3+jpgXFu1S5IDxMDHB4bK/6+2OCEmFl7V+Y2XM8GjKiS7CEllTuT4bnp4O5Wdm3YI+JXPVf6/g9juGTeaYVVYGebBysn8fOWtBf0thVZCYtCzYs4nTYcJvUzIdazfgGsC24jA/ByUiuFmcLmm+wLHL8V8CNBe3hs6AISPIjJhqnhAoKjrxXDzOo7U8WXzNDTB7xK0= X-Microsoft-Exchange-Diagnostics: 1;DB5PR0801MB1432;31:YINk+qe0SdDQ2L1ObJIKzE9AAkLH6aDPyP+6nd/fBwqUgM876zJwICSn+kFHDaewsgn3ZPlJYwrlJyqePH8MZ/y/2snsFMzhj1azJO6qeAawBa4ODjSzzDl8wl6NuigUD8mEZITWCMySOOMOYgZ/aZlkjxYJwlmupeHVSwUw8jISjnTtnUVFSlCaE84fqnsEEm2BzolQhoaxUzIIJYOkGA==;4:UFoPyh5RfhaA6tga+UmYjGC//rX0rMcTP80sPqy8fDPowG/BiMrpjMsC4D9HuCyw27+7Rsr9gLssgsuDSeWK7UWQ2HsKzt5JhFh6/C7tEsEdmi2opohZaEXc0ANW6/VCxd6eO4A3rHgTxybA+DrALiQP+Mm5sWMGSNa8iisj2Mlm/YtMneZbvzF8msmPXC4TS5leUF+c3Db9G4wkI56KIe6lXyUx+9Sz9pfRbQRJBQRdJnbW2h0XP7gVRYWsd2IrmVYRjkzCfDsz68DzOw6+H3msVe129aAc9CFPonI9SQOgXybjS8h4bIwjS9Eg/1QB80ZBxR27fhN7DWExTpzfUs+4D5kM+NmAA+mlzHOnopm3KIj8WZ01UM195v4acrQJRIFevu7wvdmN4zviwKGCBoHv4sMzw22RFSjruBNCZtE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:DB5PR0801MB1432;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0801MB1432; X-Forefront-PRVS: 0997523C40 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(377424004)(24454002)(93886004)(92566002)(2950100001)(9686002)(66066001)(586003)(47776003)(81156014)(305945005)(7846002)(6116002)(23686003)(1076002)(3846002)(2906002)(68736007)(42186005)(101416001)(50466002)(54356999)(33656002)(7736002)(4326007)(8676002)(4001350100001)(110136002)(76176999)(97736004)(81166006)(53416004)(77096005)(19580395003)(69596002)(86362001)(105586002)(83506001)(189998001)(106356001)(19580405001)(50986999)(15975445007)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5PR0801MB1432;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;DB5PR0801MB1432;23:SyBFf8zA7jvyFHxEjONNtvehW5c8HhnPEQ04d2CwQ?= =?koi8-r?Q?bv5IZNYa6iU8sLXlun/fnxBrf7CPajWR4PgkpvkDIrHKnRVLgyyVehxMyjp6Bd?= =?koi8-r?Q?a4EkWeIoap6KdP0VuqTYxEIhas62MS0VrfX27YDChd6NcAtPekMj1W1vd/UL/q?= =?koi8-r?Q?PWzX5WAUZsubEvDVSxqx9vhFAmJx/XsxmXalBQU/H/S6SjuRA2Oj73zVSPf7Lc?= =?koi8-r?Q?5tGUXzFCwAs339HgfaIbCGPRMG/U70NbsMZPmbCC5Cavj0othcG7Ity5kvESE1?= =?koi8-r?Q?AGja4B/dcxIn2IVgc+kZNezUxKO8mlFi9pqG9vqLfjIQnAgtpps918LXljt54h?= =?koi8-r?Q?nOEYZ3d8+Wt53I+MtKEE5tJYY+m1iotnaWoTX1lCU5htQen3aDsfI2P/5rUExm?= =?koi8-r?Q?gS2enzNtylee1xYXFItFNZWDIW2R0OPs9SJMltpGTMRYB4EV9qWEvzwXTJi79D?= =?koi8-r?Q?Ku72WY3vxknoS3Q3ZGZpZV6utrwAyuL0XAkjBnQubXI5kT5TxrSM0bzI3RveEq?= =?koi8-r?Q?zl4uIRTtqfrN4TZpFLs9cqSNB26VmS1z7OTA/JiYH0dNT29Zk5Lpk5vALBlnF8?= =?koi8-r?Q?CvsFoVNEG7k/VW26xzme+myWNtmDmP31OOwVGMYtu8xXrRBu2WEAPnKBuPqIU+?= =?koi8-r?Q?GgR+1QcYYLwuNTn1Zc+Rzd9Qs6e3bawBl9+HOvn+mUwjHZFGdct5N1wTctE6de?= =?koi8-r?Q?oJI/aknaFDWZudt1cbiLoXD1zKVZdlDUR7sNG8Q6VywvtmnQ4eJyXPZBkSzq6h?= =?koi8-r?Q?S3p13wszaTXBYlcr2iCYJB51qpc1Dy/h30lGPs+MrJCsenRjmzEY30opissW+/?= =?koi8-r?Q?8L/04twE2cgTZNx4LtuO4q2oxUxmRn9yYhrWa7H8BVfF+Ivm/vykmahVBHkQgs?= =?koi8-r?Q?ArfxQlQatMvlZNnQt7RSHeFmScTqYnRydPC+iyccNESirYuqtpv4OhupxlezyF?= =?koi8-r?Q?0i7xnNBCYsP0Em2iUgS8wscJAOv09Fm0CUNAIFPlbsklKkLqAVZkZfue9WR2KL?= =?koi8-r?Q?qEoI3R6nJQYH/aoBj+VN15OeKxQwXeCTPzMv+sSA0IVNvlAYhEBg8p87QxGShn?= =?koi8-r?Q?ZvCHSI+R1ZlNMvRS8toY9CSYZ2K4K+Sd2jl1R0VqjMOeRnAWSMYoqTa92xUDe3?= =?koi8-r?Q?A9rae2X51fqw8xyAFCirh6O9UXU7JlngdOcrh2rBBKJFplxVOIDCROsnPE/962?= =?koi8-r?Q?7OBLuXHts2u8FRVrp1nRfBVzYLHPIzt/qdEw9iJk=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR0801MB1432;6:hA5R5/Pn5oBJ+Ebjo3DSpS8PjyxIHGHOdPahCKJlcTo6TlbdmYTHsXADoc97P2YRHnCbGXeejDNlFmB2C3MmahjvXMk3HoCwK/OHzSfN53GfxAYVmukKsUtBUjKh9T2Rhjs/xbCkr2Hf+jUIauRA/9ENKSM1l3niDdv35NBTjs0pBytRnT6nu06rkjIE/8eViJ0T15eRPRcq2HUVb8yFZr8bX/wItUwKpufYlSKxzne72f4jtk9hMAJzzCYUTewPpr5bXXPAR/w+ipS6cV0Vx7xBsaU06TO+QtZF00JhlbmfsrU9HOfP7mcomoPihaKZ;5:AA8IrMeGxph1Mq02P590jSZ2AX0/2PPh2C4TDkGRkLqYcX5HWL7crKR55gcDopM7F6dZJ2hXv1NSkliUN8cX1nLawUWGMWEQJg54KnOvwuDFc9OK7Mo+Q+TOiW+Q1c+WX10Q1XA8BM2zVJqX56f9qA==;24:F7OZEsSp2ztIKAxCWqhqHtf/cXtFVHRZSN2e51wRDGOwEr8mt9porTtTBzfY2cKc7NLdnwg8a2djRLbfp8Lf+rG0XHc78HWgtAFQuFgYdo0=;7:QxcqMSmKcOMglpAKoqn42aIYm07RZ4Kea1y6wQj3Novp1B9O2GjTyL7FZvgN8WJQ/Gime1jW+xUc443W9MfjSQ9yWnKmvGjeztG+xGjlVq+h5xp9Jcw+s+ZmIoZrDgC9RUIxnO4CGACIeddlvGrjZIkQXQEi/g6jByUcxua7Q7KMCxqGDBZxHNFa/RXmvAXeTfBRznEc0FO/2YOolKjvtxYrLQD5S8sPr+NklwlD/aQRWbDAiueC6ZYlIKBzq4ui SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB5PR0801MB1432;20:S+rpYLdmflZc3BI8zDOFG48n/7OBGUrPrl8n/jGZlyzJUSZdnWE1ZegLWwuvHK7HPw2RYPp+RzhpEu8hMWvUoBybY0eR1T1boI0vozDcJXgHmjeGXRpIXwzZQIxvV0joN4hzT4XXFvvt5ds6X+iVBW3NwQUiCDiflw70APPDP/0= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 02:16:32.4360 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0801MB1432 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote: > > On 7 July 2016 at 17:01, James Bottomley > > wrote: > [Serge already answered the parenting issue] > > > On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote: > > > > Hm. Probably best-effort based on the process hierarchy. So > > > > yeah you could probably get a tree into a state that would be > > > > wrongly recreated. Create a new netns, bind mount it, exit; Have > > > > another task create a new user_ns, bind mount it, exit; Third > > > > task setns()s first to the new netns then to the new user_ns. I > > > > suspect criu will recreate that wrongly. > > > > > > This is a bit pathological, and you have to be root to do it: so > > > root can set up a nesting hierarchy, bind it and destroy the pids > > > but I know of no current orchestration system which does this. > > > > > > Actually, I have to back pedal a bit: the way I currently set up > > > architecture emulation containers does precisely this: I set up the > > > namespaces unprivileged with child mount namespaces, but then I ask > > > root to bind the userns and kill the process that created it so I > > > have a permanent handle to enter the namespace by, so I suspect > > > that when our current orchestration systems get more sophisticated, > > > they might eventually want to do something like this as well. > > > > > > In theory, we could get nsfs to show this information as an option > > > (just add a show_options entry to the superblock ops), but the > > > problem is that although each namespace has a parent user_ns, > > > there's no way to get it without digging in the namespace specific > > > structure. Probably we should restructure to move it into > > > ns_common, then we could display it (and enforce all namespaces > > > having owning user_ns) but it would be a > > > > I'm missing something here. Is it not already the case that all > > namespaces have an owning user_ns? > > Um, yes, I don't believe I said they don't. The problem I thought you > were having is that there's no way of seeing what it is. > > nsfs is the Namespace fileystem where bound namespaces appear to a cat > of /proc/self/mounts. It can display any information that's in > ns_common (the common core of namespaces) but the owning user_ns > pointer currently isn't in this structure. Every user namespace has a > pointer to it, but they're all privately embedded in the individual > namespace specific structures. What I was proposing was that since > every current namespace has a pointer somewhere to the owning user > namespace, we could abstract this out into ns_common so it's now > accessible to be displayed by nsfs, probably as a mount option. James, I am not sure that I understood you correctly. We have one file system for all namespace files, how we can show per-file properties in mount options. I think we can show all required information in fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read /proc/pid/fdinfo/X for it. > > James > > > _______________________________________________ > CRIU mailing list > CRIU@openvz.org > https://lists.openvz.org/mailman/listinfo/criu