From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933186AbcGIFau (ORCPT ); Sat, 9 Jul 2016 01:30:50 -0400 Received: from mail-db5eur01on0114.outbound.protection.outlook.com ([104.47.2.114]:24992 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933082AbcGIFaj (ORCPT ); Sat, 9 Jul 2016 01:30:39 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Fri, 8 Jul 2016 13:38:19 -0700 From: Andrew Vagin To: James Bottomley CC: "Eric W. Biederman" , Linux API , Containers , lkml , , "Michael Kerrisk (man-pages)" , "W. Trevor King" Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Message-ID: <20160708203818.GA2602@outlook.office365.com> References: <87r3b7pxja.fsf@x220.int.ebiederm.org> <20160706141348.GB20728@mail.hallyn.com> <871t36kbvq.fsf@x220.int.ebiederm.org> <20160708015758.GA10512@outlook.office365.com> <87vb0gy3nr.fsf@x220.int.ebiederm.org> <1467988533.2322.118.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1467988533.2322.118.camel@HansenPartnership.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [162.246.95.100] X-ClientProxiedBy: DM3PR14CA0047.namprd14.prod.outlook.com (10.166.156.143) To VI1PR0801MB1438.eurprd08.prod.outlook.com (10.167.210.18) X-MS-Office365-Filtering-Correlation-Id: 6320a9d9-fcfd-4c38-8719-08d3a76fd3b9 X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1438;2:m8ce6rtRwJH0gpwgMJkRqhD17KjwkjIs6ugXK0pBdQuiNYkxImBDP5JRMwW6K+j2ipMvtJaz1IIqFdWvRoDU7Pr5zzzQBBQLVYNMLbs+a7drNft8RTiufcPFVdhDuXxSy5PCWmqDBwpkDvFFwxg4EuVGaVo56kKdpOcO4iWr8CUmkBzt4uhuGDgrUUreAWQP;3:7AEvMWjIhbYL8ERq6m8JamEHJlfyvQoazSfrcaNvt+FotinLHnbHgtplkhNvThHBXgmPxuVuc+Fmbw6A9AAPZj3/lDZmCsJfYVdqjlUula9pde3o3jgcYCQtRX3qTJ4V X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1438; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1438;25:TjyLrXxqMrcMQZxBBk0EsPYwGATERKIMI5hqv75X/v9l3RsidtslzMc1GvXayD3K70r7qonIKZG3yAe9oY4UVna8t6CXNLB+zzrGZWKulPGqKwgnga48WS3Xodi5PT7S6fKQU91S5MI+Q2YUk9tDlg6xXr6zEnu/v30gLqYVWdTLehG1jSL9C81Y3U4p3Wg0eDIobMeIXhPkBKQvsvLeWyGZb6KrR4p6FJSMvPHwVqNxpbQT4+byMRn6tOnfha8axMn1XT8i+qmCXZZHQR8kJY+wBlKHvy5i2G3RbhhmhX0QzpF4Eq1R8sAofCJ8oO9+7akjCt9jKauFWq5U1qXbcITIvMBGf4I7SP+RECM3p7dg/YHIVShqVpHARjixEyAuzIyyyVFBA6ymFYz4oGvtP6QPR2+bYWHITK99mJWEB/MSTB0Rb+FWXlv1xK49KTj2TbLGqAvJCXyT5wQTJFzNz2F9orsXlV89b6sPXtIQwYmtSQYaNvBoB+VCKzDarl7fxwOeDHLXj7wIUnM4GxW7+naXEv4mwyi9nrPHRt9rji1PfkMZKcQimaGppZHrgj926zucc6EXRTk/TZqp23/4JUbkcTBwEVM4QnuoVovSgfzwaaVhqszU4jcsuOYv8XtOtAM9zfdtowIhv0XfpIZp2uGhmPgjMKxdNbLmyb4QeDxxaYN03SpR2ZluMSbMB9cy2LL04O0nzbNzv3wf/TVDTvooys8UwvK+/ya3swxYImjzvG3RPfdtACCmb7qNoRWHeWTxe+lJD6iO49HcCDxVAKaly5bYXtMZnvf+eQuP6S0yXgM8q4uwHdbBVmvUbzw43Uxv/27Ake/Wl+ZVnI+FgofsszId8rsIeZ6G4iiTho8= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1438;31:qZ3WSvJpqkJz6fEaUp7PH9Y5fCzlhvDlNQ6M97ojum5hu0cb3TcAvOuzM2Z+vVLx59e8N6bsstlqwcI+w1FQTVnYD7vtfbPhLlX5Y8w+ydTCHg4IoVAcaU+Utzm5v8pBhCFdspQuCuSbTqeFhWh/8xq6Aa3AxUk8G9gXCW9VQ7HOUG+BsOAmpl+vcxSJRyIcimpyys22tTqWgaR0x1Swqg==;4:LILrla0+n2G0a853IAdZ0dor760FA3BXnuiOom3TuAN449RjnPhiE9OEMl76GAV2mI1rquQqLbEfe+AVuZ0soCue8XVwbX/7PQjAePJIaYymrTmP7YtEjM72qCYSaKcNXm+DZI8VRGTT4+elQsHJH4NoxpiA21cjJLvElvJja61AqMJUjfrTL8NVDVF0hiotZ82BI+aR1IKcfNFMuohX+lwwzwozNZUAbufJOp9WLcKVtSn8YWHyUC93Lm+Zm3z6XeYth5JU/+QN/UZHqDOTYNvgiH6HxYs9PhVrRVyYXEqCXkijegR1AGkn2RdZM0aC7EXBvVFwnevEYZdz4O5AVtae8TNb7rFRbp4/4DYQyDUPSalsU1UThhtTyfeRmz5JgtJv4G5egNJdhIVLfkw3+VLrETdEn0B0I6TCVPU5NdV0rHGQimcz+qkxbfDkRtP1gVb4KT31Q/G9KSBPM8cGbgwKksKVDV9jA4srRVsg6U4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:VI1PR0801MB1438;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1438; X-Forefront-PRVS: 0997523C40 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(377424004)(199003)(76104003)(24454002)(189002)(3846002)(50466002)(33656002)(106356001)(19580395003)(4326007)(105586002)(586003)(19580405001)(1076002)(6116002)(92566002)(97736004)(4001350100001)(69596002)(83506001)(110136002)(189998001)(76176999)(50986999)(54356999)(101416001)(86362001)(42186005)(53416004)(93886004)(9686002)(81156014)(81166006)(305945005)(7846002)(7736002)(2950100001)(23686003)(68736007)(8676002)(77096005)(47776003)(2870700001)(15975445007)(2906002)(66066001)(7099028)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1438;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;VI1PR0801MB1438;23:VkWO2IVDPOZwjFuzgRzIKkpDD743+KESKHPyRIIhR?= =?koi8-r?Q?bvvgQV6BNElNav7s2dExz/hhAoRdYN1660fgfdxPOeuKp1Ru7knppVTpuGsBFZ?= =?koi8-r?Q?t7oSGi2lWMKCCGnlA2D+n/SlqkUl8u76M0HxAbOQ4wsggej+PT8WN7/njSoqQ/?= =?koi8-r?Q?HI/bUhCxnTW9fNOhXSgUdwWI/X+kPrYOtmbzsZ+0ImKTBUNIAf67ucIkpCpV4H?= =?koi8-r?Q?eufHbmKMB2XXhXoE5iOL9ueM56hRrcPlOjBrRo9SvR3RqsOonN9aoGFXGjpFRh?= =?koi8-r?Q?44fdCjOgnVNv96cjyCpRi9OQmyJ0s8wYrIElepS2mLWuLoVl5TWbB/5jDLUDD6?= =?koi8-r?Q?zsM7PMyUW7S46DwYBsqWlBIzxXVSXf/XtDg/3g0qsh4CcatXa5UJRYLVXzo6hG?= =?koi8-r?Q?4BezSQ5X8LZiYj5Cr6/MDtBhQhEwYi9iDOu9HwjLyMjm7IxxsGrvdM4wYHXdV9?= =?koi8-r?Q?zAH2KBAEdbiJLzjK5b5PfXQzx06XpYC1gTZkjLzcZq79Y022BImTf+euCSDy1u?= =?koi8-r?Q?TaklzKH8nlf/Q+XOgZNv7UMz9Ak60cBNmCuEmeIMBKDiSQ+HLPnW6J2BrPEGL8?= =?koi8-r?Q?fDq4vgUlD6CMPloxbdvCD9VtNefemkbxRqFK+0fvMgcQQ2ZPEGExhgxMD4DBnX?= =?koi8-r?Q?0VrMeQN7UfJzI6z71sEVRnxYIjcBHW7zDxmawaW/pW8dSkMN5t0SIylvRjuC5D?= =?koi8-r?Q?GTFMZJSbxl7b0efcBl7R1aYVb3LmzEV5QRnNKxW+NdUqOGt2BZS0jREeIfOuHu?= =?koi8-r?Q?2hmtV5z5Ed5H2NXssYGRPPBzeeddvyX7IPoMQqhvEGvWj7USQ5GA6XNSNA2XN6?= =?koi8-r?Q?/50TSpbRB+62zSvRdkZ6rCxIcRmpg0lRdj+cB9erVvCzGHTHwMvxZgIrdsTjAG?= =?koi8-r?Q?Uyzfm8ANL2hdbmCARDoXdAgvIx1E8JLk6GoyOSlcm2Kwy4VqqrRsUbddZI6r+0?= =?koi8-r?Q?XOde7JCm3voJH9cRgxVdG7zcAFXymB/OrsYG7C6VFfVsW7WXu3fSjlJVNyszv5?= =?koi8-r?Q?qWKan7xJYC99rt6jZOQfYcm7cUbmjiuK7NfW270k+c7Pp3EeGigR1YLV0rCla3?= =?koi8-r?Q?oDLDwen2OGAByHzH+MvNkg51edX3Qy9xUO5G2+ukzyYyD4/0l4ZbK7EDG8RLvv?= =?koi8-r?Q?qiRgdTPdCCCV363T1QRokkriLhutIapfWavIztrGrarYIX/jMZeLZ6tXIgyANq?= =?koi8-r?Q?9rfJybC2KgsKHwWKSp6HdtrcVj/Vy+2isnl6E+PFd8CtoEoZPUgZKdN7VQU8g+?= =?koi8-r?Q?UmhDcthc02yN1Io6ARZFTd4Cg1bfQGFrCC1Qi7rOX4=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1438;6:SLLD24cbW2W4WPcKHXsR7SuPTiLc/aDmdd9QpvBuGzxmXNtapuc1cEtKJLSS5sPmG3K1FyeGg7jswK4CsOA9wTLXxv1WVZqFUcEjpAOqLsMfb0lwhgtp80qRa65B+RTLqRlHcHVPEcDVoOlsG+Fi7edyAJ5cvEDlDLuozOl5aaShmcL1tddiMypENPwNku2yz8FK2UmExMRcVKvvyUjk0Q+cr5Z00FBKhTj0d6VEuMZwa9Nsghbs7ROzCfvniBB9DVPedgvR/C8nbbdHjTq/fSPaz9OueT6x8Nr5c1OEuiGS13cUGTLa1ZcB3QqFBYsk;5:TdJhSM9MSc8QoQgGHfaFBvlmO23pdw83gBObkBUv3dCGWkzFQ+X9Rvn3cR7XafoQ+iZPNBqWhkG0Rj7eA4Yj8iPJ/W97pZv5bpfEm5nV8fKGERxtsNHuoqg2lrE1wVLOhTHkRbl11PUxW+afpaEAkQ==;24:PoGt7WMBjEyLiiLQXj/C+z1jm2VPKF93OiFns0Ev/jjfnd9GzLullU2VfLg53y6QS+ScViak/wpYcVR4UDqXNxzxv8cr3RP9Umqs4doEhy4=;7:4oSSwFb3erQNv/y/0F22hr7hAGM2tdbZPfxLC5LcX54DWXsXlFYRx1RbdpFFDH0FWdlfq9Fua/6fYzRUXbECfBwncWbNNwbjbCMDritr18Y9K0zl317l5NQa+KuNHN1RMfKaPOUKeyxCpZYLYTnbteGQVA152U/HZsUsi6lK0O/RIJoR7T6/whK1nbDZDZAA3SNMTUz4uqHMdR3wcXeeaoIEtP0KOvxbucU05ShMYtMGZZSijBvPe/rfR7zXLcdn SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1438;20:8cL/mtKqcBZeGMlXpCVqaxZyDm+2zWZsIgO30CbPcrxtC5Z7wqpgT6wmoTSWh//fLTZ4ehwiaPV1p/clEefmVr+YbmogKvwMJuuuJXU4QsizIRLLX8ibDsCIOysrJk5FtgM6s+h80vJE3SxRLvbrvnw8zMrinQv1blUeIN1X8Cs=;23:dLdaU0BsHV5rjsDeIiYPhiQgWh0A8g383gSHlzCOXRGMvE8FickxN+d5R5tp0dRy1UsZUNZJuW6MKZzlOcYJ3WV6l1XJ76lusKhg7XzuS9OoSt/0zLZXZW5xKG2eZdqlGF0Xkngt7hK0wi1ICBoqbktS3bwexM9IQ0vSbG85mFKGurIgHOGGfboN/xuToQMP X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2016 20:38:30.3002 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1438 X-OriginatorOrg: virtuozzo.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 08, 2016 at 07:35:33AM -0700, James Bottomley wrote: > On Fri, 2016-07-08 at 02:44 -0500, Eric W. Biederman wrote: > > Andrew Vagin writes: > > > > > On Wed, Jul 06, 2016 at 10:46:33AM -0500, Eric W. Biederman wrote: > > > > "Serge E. Hallyn" writes: > > > > > > > > > On Wed, Jul 06, 2016 at 10:41:48AM +0200, Michael Kerrisk (man > > > > > -pages) wrote: > > > > > > [Rats! Doing now what I should have down to start with. > > > > > > Looping some > > > > > > lists and CRIU and other possibly relevant people into this > > > > > > conversation] > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > On 5 July 2016 at 23:47, Eric W. Biederman < > > > > > > ebiederm@xmission.com> wrote: > > > > > > > "Michael Kerrisk (man-pages)" > > > > > > > writes: > > > > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > > > > > I have a question. Is there any way currently to discover > > > > > > > > which user namespace a particular nonuser namespace is > > > > > > > > governed by? Maybe I am missing something, but there does > > > > > > > > not seem to be a way to do this. Also, can one discover > > > > > > > > which userns is the parent of a given userns? Again, I > > > > > > > > can't see a way to do this. > > > > > > > > > > > > > > > > The point here is introspecting so that a process might > > > > > > > > determine what its capabilities are when operating on > > > > > > > > some resource governed by a (nonuser) namespace. > > > > > > > > > > > > > > To the best of my knowledge that there is not an interface > > > > > > > to get that information. It would be good to have such an > > > > > > > interface for no other reason than the CRIU folks are going > > > > > > > to need it at some point. I am a bit surprised they have > > > > > > > not complained yet. > > > > > > > > > > I don't think they need it. They do in fact have what they > > > > > need. Assume you have tasks T1, T2, T1_1 and T2_1; T1 and T2 > > > > > are in init_user_ns; T1 spawned T1_1 in a new userns; T2 > > > > > spawned T2_1 which setns()d to T1_1's ns. There's some > > > > > {handwave} uid mapping, does not matter. > > > > > > > > > > At restart, it doesn't matter which task originally created the > > > > > new userns. criu knows T1_1 and T2_1 are in the same userns; > > > > > it creates the userns, sets up the mapping, and T1_1 and T2_1 > > > > > setns() to it. > > > > > > > > Given that the simple cases are so easy it probably doesn't > > > > matter in that sense. > > > > > > > > However we now have the case where user namespaces own pid > > > > namespaces, and uts namespaces, and network namespaces, and ipc > > > > namespaces, and filesystems. Throw in some mount propagation and > > > > use of setns and things could get confusing. It is something > > > > that will need to be figured out if CRIU is going to properly > > > > checkpoint containers containing containers containing containers > > > > containing containers. > > > > > > It isn't a joke:). We have a few requests to support CR of > > > containers with Docker containers inside. And we are going to start > > > this task in a near future, so we would like to have interface to > > > get dependencies between namespaces too. > > > > > > BTW: CRIU already supports nested mount namespaces, because systemd > > > creates them for services. > > > > The tricky part about this and what messes up James proposed plan is > > that the interface needs to be something that returns a namespace > > file descriptor. So we can't print something out in a simple text > > file. > > I actually described two problems: the first was how we get the > information in the first place. Currently the owning or parent user_ns > is tucked inside an opaque structure. I think we need to move that to > ns_common where it would be the owning userns for all non-user > namespaces and the parent for the userns. I'm agree with this. > > Once we actually have the information, we can also add a set of proc > links, say either > > /proc//ns/X-userns > > Which might be a bit messy since it doubles the number of files, or > perhaps in a simple directory. In this case we will need to enter into each namespace to build a full chain of dependencies. It's tricky, because if we enter into a child userns, we can't to enter into a parent userns from the same process, so to get the next branch, we will need to create a new process. process A | init_user_ns->child_user_ns_1->child_userns_2 fork() -> B B: setns(/proc/A/ns/userns-parent) readlink(/proc/B/ns/userns) fork() -> C C: setns(/proc/B/ns/userns-parent) readlink(/proc/C/ns/userns) > > > Well I suppose we could print an device number and inode number pair. > > But then someone would still have to scour processes looking for a > > user namespace so that is likely less than ideal. > > There's no reason any of the proposed methods so far have to be > exclusive: nsfs.c has a lot of flexibility. What do you think about the idea to mount nsfs and be able to look up any alive namespace by inum: $ tree . . mnt{inum} user -> ../user{inum} pid{inum} pid{inum} user -> ../../user{inum}/user{inum} user -> ../user{inum} user{inum} user{inum} https://lkml.org/lkml/2016/7/8/59 I think it solves all requirements which were mentioned in this thread. > > > Starting with 4.8 we are also going to need to be able to retrieve > > the user namespace owner of filesystems. That will be an interesting > > mix. > > This is per mount point, isn't it? so it can't be in /proc/fs/ and it > would have to be per local mount tree. Yes, that is a bit nasty. > Sounds like we might need to unfold mount or mountinfo into something > that has one directory per entry? If we will be able to look up namespaces in nsfs by inum, we can print an userns inum in mountinfo. > > James > > > Eric > > > > _______________________________________________ > > Containers mailing list > > Containers@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/containers > > >