From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbcGHGKK (ORCPT ); Fri, 8 Jul 2016 02:10:10 -0400 Received: from mail-he1eur01on0110.outbound.protection.outlook.com ([104.47.0.110]:40688 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750985AbcGHGKB (ORCPT ); Fri, 8 Jul 2016 02:10:01 -0400 X-Greylist: delayed 8305 seconds by postgrey-1.27 at vger.kernel.org; Fri, 08 Jul 2016 02:10:00 EDT Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Thu, 7 Jul 2016 23:09:36 -0700 From: Andrew Vagin To: James Bottomley CC: Linux API , Containers , lkml , , Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Message-ID: <20160708060935.GA14391@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> <20160708021617.GB10512@outlook.office365.com> <1467948005.2322.84.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline In-Reply-To: <1467948005.2322.84.camel@HansenPartnership.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [67.183.159.197] X-ClientProxiedBy: BY2PR08CA0014.namprd08.prod.outlook.com (10.163.62.152) To VI1PR0801MB1439.eurprd08.prod.outlook.com (10.167.210.19) X-MS-Office365-Filtering-Correlation-Id: 8b56f141-0678-4d6f-ea9e-08d3a6f67af9 X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1439;2:xy5W9SAufxPQKy55Rkagwb+fRwXfdkCRwTWXj6iEo9gcDfgrWWxLkNBwo+VxqCtc8NXqklLqxa6tvcUWzBO2pvRtm3OB68AsuQR3zUnv2XNXVqLW+PvEka/DfSHUw3KH04CzvHCu0opsupwUhGv7khW1WC4Qs/G2mMML3YrKtlPELlyRY/4iosKXqGYvUN5o;3:2VogVDb7+qU50QSOWKzKYFKVNj/LbR6mWrjoRHGefqKWyIy5MhnydkRX45FeexGedzgDsRBqNPIN3MZddC/p72CwKH/WMX4cZZyW+ULxBKYtPHFfulxKx4sdiyeyareh X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1439; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1439;25:WH87ViPRR7EINPcOfPvMJBKanJIx4rSJWzE3SydDRUNpovfKLKUCTEr5aX24dTcxrqgM8bBpIDZ7rstj2ZJUZdiODQCpkpRYlAHLdRAYygEW9m58k8XBmWT22SWtYphyl6JHvMHV0bscu+Sfqw0VbHs4TXv+uC9t7d8ykklQCZhGqoz6BLO4mjddPRAw/Wypa2L0HyG2/vX1xNoBr2zN0fhbnv5iaQ32vJGmdd4WddApPr4XbtMdudTy1hq+lahh32c/J9ytzN0QvERFJ5v/0/suQjud9NlX0GM5h/dU1BTuNTpDCD4xk2YNwx0wcXvCVyCPbA7nLtkpT3fuvYm+nA0pqMAF5u9NANz3Kp/Rsmv/5K5TfWKyx7SNVmyEb6YrtsDueK7fkqzca2t0TRh/8IgOp3+Gf/3iui50+8j8XGl6AQt1kxWfGZeM+fP5dHwlL8QjeY4ciVQcCZ7VdMegwncrL+ntiGqW9mEG9BgFSWKK39C4NP+6HLAu4qskdR+lx5FDoXYvqt3QVl9pvda1qw8OOKbxoy5vduD/fmrbykt1PK0PbaIrKUiIi3y3dT5yzBvVYL7xbA/OyelDF4W9P/p2efnk1C4hfobSRXwKjz1nD1/oTphqsUEUza+048C9o0bxNKCGhlpOwtV5kW6CnBwz5fxZwgBHdb1AC20DaVt+oQacsu/RhBw2q1L8ysU9sKlYdv0r7DuF/WDbBquNckQLwQL7YbAVymrMP5qlsLmbIe036eVQN9Z1yUADpOqD X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1439;31:n/VC/BdYiNC8m6Fa89SCr9LVuoYTSs+WtcoGdn+NoS1CFE3avJkOWCiP5C6IdJCoEWSmO9NFzYS+xsflIyueWbI3YcUD8jXvTwNbDmoR28SjTB10YLfBfS9Azd2o1I+YgYK52iiXpIO0kknOlafPt8Sbkqo5lmoThWOgZw50I0w3qhVrZ6HhOKt6FPgquxZefok+Ez4sMb1eITqFCQQVWQ==;4:ewR0gcboNUqvVvqWxN9D91G3GQOv8wtvo91Vsk2P0tD0+g1sIlWudas8AWjnc0FoSdF/DlzeZagg5TXGOabBaHNE82Swd50DTuYytfl9h+t5HPjBLJC0IElZzYxplVK/unPk/wHDXZuFewwbIuEOjrVN6nPixofRaxvIqKOMQ4eeltLBdGd+WYOeicw7TAi+9lE2Oq1OBez3qTh0QTRyPfWyB77zyIFLC4s7gJAZIQ6xc+Jdsgx0/BlNn36Q0wK3XjfYTGZgGC8GzGQkm6d36i8eyGLXdTGCyel7tk9xkkcUjLTCfQM6iyy8q3eNQzg8MK/6DPVMJActevK+nAJwc3pxjjkV21tDStbaNLXewT0r4fA+X9flIN6/7q9X+SvRinURjrLXPrtN2CFd4zd7A2O835qvH1Vl3HtVCo3UUls= 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)(3002001)(10201501046)(6041072)(6043046);SRVR:VI1PR0801MB1439;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1439; X-Forefront-PRVS: 0997523C40 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(377424004)(199003)(24454002)(50986999)(69596002)(33656002)(76176999)(86362001)(9686002)(54356999)(1076002)(105586002)(8676002)(42186005)(68736007)(189998001)(19580405001)(19580395003)(97736004)(4001350100001)(106356001)(23686003)(66066001)(92566002)(2906002)(6116002)(110136002)(53416004)(3846002)(81166006)(101416001)(93886004)(81156014)(47776003)(77096005)(7846002)(305945005)(2950100001)(586003)(83506001)(4326007)(50466002)(7736002)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1439;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;VI1PR0801MB1439;23:eXd1UeZoeM/WdgQ52BNbaYSW2scgPAAaKlG+iTJXn?= =?koi8-r?Q?geypnqvA2zHEBMPxJxGz/o/NHPUzAgBb/hc7p0BEc3VwpBhwXIScqvktkw6YVu?= =?koi8-r?Q?+Kv5d7Tpxxj9qfp+gV/cmczg+tYCiIfSBQ3L2z3Rl8omo93KelyyXYo2X3AGJa?= =?koi8-r?Q?OEj/ZMnzhoWsevsXa/uwRT+xlgO5E4xX0KCYoux/p/HJI2+dbpbZPFbiCqzauq?= =?koi8-r?Q?FTpqGtGcL4QUemBBqiiyBdBMKbrv7pVY8+9aA87foAg8TR3HCpliOHMnw8Q3WH?= =?koi8-r?Q?j43upmkRZzC8gydjZfH+2EbHf1qCoH03UsE28miB7sMhG2YfpIbDGCLcbt4bgv?= =?koi8-r?Q?zUzkVvkH3o/uTGO+luo8TdKfCI0EBTUq8+1V1PwxTIOePgTwbSXlA8PbktOJXr?= =?koi8-r?Q?4HFNa43cm/aI1JQabZIufVKn2tX7f4eca4aHHRM2L9qN3Zl3yGFojuROHJsZSP?= =?koi8-r?Q?+gzzVae0z4Qec5Bx9gq9o3P3cIa0vNsGCOEoX5INMBw52Mrluq/EB3jzGqTGzR?= =?koi8-r?Q?vjwbLmuaEToypsdF1TTGXRL2cFSk3bJFJHkm4BozdftA3CYEAGn8eBuyerMB6V?= =?koi8-r?Q?6c1pjXv5ASjA1rdtjcSK/iei/u0qJnHZzAxUCfUnu5LjYdQr6g6XYkUsgV9C8P?= =?koi8-r?Q?pTCRh81hCU6fR9ZkEv7YnwG4M7fw7NQk2lNrnk8Qzfot5tEY7FC6jSYZieG4lX?= =?koi8-r?Q?K0Vvyiyex92Sm2VTwp9meJIpzrnTaZ9rCo4f3FQTsx/gKOVB6ujswYGP6AXEg1?= =?koi8-r?Q?1S4sdU/QNm/kDtNIpcw1D+Th6z1uS0drOHrojZyb7r5c43KXVgT7eA2LbuZaiS?= =?koi8-r?Q?G4iTBUk1eZUdLvWY9m9pZoYe2UWd3UhAqTfd/DTYvMeb7GnRl38KHEBURX5N8b?= =?koi8-r?Q?kmH+XcqwAWmG1mtg4HU/EQYpdRi8Z9zLw+t/MenXeTEj9wAwdk83etFQSixt0k?= =?koi8-r?Q?X1tp+QI513fcvh4y0hcVz9hp9txYpGvEdO1AH02AbQpjugyLZDlDLGWsnY2+fV?= =?koi8-r?Q?J7zLjDDaJEQ/6cA6pt8ZjvXiY5hFg1SI5PK/G0eq1WIUNo539cG/JHSpOPUqU6?= =?koi8-r?Q?Ov3hEpHQ7/rONKt1uue8zJ0WVPDWaXi3v/jqnYIxm+bIyLej/ecsSGXLS61vFq?= =?koi8-r?Q?nSjMExyflFiTuAZrc8u0lHGEqllnc61DhLzlygY3UlnmaiPgZmqvOUgqzLLsD2?= =?koi8-r?Q?vduUqMMdrazqziYBwnw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1439;6:xcefDszKrlKe4raRK/6EfzbGp4ZEIv7zXPEt3l0eiwKT7wZyX0/LVVvaCnqfhpeQKaNlMv9JRm7HrtWIcNJC7F1mrGZP6cyNc4vbx4K7WwqXoOxRVfjIAQKXJv0OQJBS0ag6Nnxg4+JZ8oMJgyTcsh1tcmUMMTxtbXOlQUbpc81w1fhk2EhM/Nn/Y9tYKkU15+HP/8qu48OvePIGZtazVan7zL38JvQLC6LRYj1nghoQNcXpcirYfrHfKBu6RZN4yP+vl1ulq4YpqQ6Hlg7aQUrN9J+qg6E/60UYqzyfAndnIaZuICdiSlxM4l78bHT3;5:OQ0mUXk9HYecnJWSyeQqp9mCxUHlI6eW3VGz2558CVQw5eYKJSdKJNCJr9yXg9qHCCqVmMhRbmAmxvpUAvSB/O4jyLWnbjWsc1IBGdDfPKdqB4rzZQIzQI89bTcu0BVnSbhcOYIIH7OtwPRqrpOl4g==;24:YrZEC8biUCDatO/UtYjMDKpSP32D32v+GV1rHskrlGTg1Woh1giwpmvVBWJ832+9cM7eH8uDZn+/MK8lbQEPfJ5GQ9HOd1n7nNDtpq98A7c=;7:7wJBOxnuWPAIsN2pZ0onl9K7Fn1yE/hV2IhQfeYv51zqh7Js/1MtWoI5dPN7SPkCNHfTBZ0YdyKoBMKlTGoIsL2B1sKyc1hVjM66C7wvx6Piezd5cDEanY9x+lWsV7KyBRDXuBScV2EYYSiO28McRH7chw39ARlAwCLHPVKzDQVzYQzerCREzYGOBSHpee3swdfR8ajWt1SdpnFlyaZKlWOR/7FuFM9DTwMQfderugm1mdBcgjjGG2ETWgpOzUNc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1439;20:dIy3DiC+ktz4YWjqs+UywrbIvVheXOwmi+XY1u0oBVWerfMqYnFW8ScpRbubJed8BZ5apIw53U7Di0o2B0Qg47Qv3Pkonngx3EclVk8TR6sbxY8RdddFvlrKgkxPR38TgQBIYGB7pRABcEv9Hu8P0ep7fMdaKT9hPhARs/DgXUY= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 06:09:52.4940 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1439 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 07, 2016 at 08:20:05PM -0700, James Bottomley wrote: > On Thu, 2016-07-07 at 19:16 -0700, Andrew Vagin wrote: > > 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. > > We have two ways of getting information. For a namespace that only > exists as a bind mount we only have what the mount/mountinfo shows, so > you see something like this: > > jejb@jarvis:~> mount|grep nsfs > nsfs on /run/build-container/userns type nsfs (rw) > nsfs on /run/build-container/ppc64 type nsfs (rw) > > the (rw) are the mount options. We could add the ability to add other > mount options to this via the superblock .show_options callback. We > could make it show the type and parent user namespace. Yes, we could. But this way works only for bind-mounted ns files, fdinfo works for any ns files (e.g: /proc/PID/ns/X). fdinfo show information about one namespace, when /proc/pid/mountinfo shows infromation about all mounts, so we can parse fdinfo faster and easier. > > > 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. > > Not if we don't have an extant process in the namespace, we can't use > these files because they don't exist, plus fdinfo on the > /proc//ns/X doesn't tell you what the parent user_ns of X is > (again, we could add this information somewhere ... not sure where > yet). we can read fdinfo for any ns file. For example, fd = open("/run/build-container/userns", O_PATH); then read fdinfo for this "fd" (/proc/self/fdinfo/[fd]) Thanks, Andrew > > James >