From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Vagin Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Date: Mon, 11 Jul 2016 13:55:00 -0700 Message-ID: <20160711205459.GA5026@outlook.office365.com> References: <20160706141348.GB20728@mail.hallyn.com> <20160707133631.GA2994@mail.hallyn.com> <1467903712.2347.16.camel@HansenPartnership.com> <20160709031528.GA25507@odin.tremily.us> <87ziprmrln.fsf@x220.int.ebiederm.org> <20160710053609.GB4868@outlook.office365.com> <87furhjkxw.fsf@x220.int.ebiederm.org> <1468184808.19833.30.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1468184808.19833.30.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> 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: James Bottomley Cc: Linux API , Containers , lkml , criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, "Michael Kerrisk (man-pages)" , "Eric W. Biederman" List-Id: containers.vger.kernel.org On Mon, Jul 11, 2016 at 06:06:48AM +0900, James Bottomley wrote: > On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote: > > Andrew Vagin writes: > > > > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: > > > > "W. Trevor King" writes: > > > > > > > > > On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley > > > > > wrote: > > > > > > 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 reasonably large > > > > > > (but > > > > > > mechanical) change. > > > > > > > > > > It sounds like everyone is either positive or or neutral on > > > > > this > > > > > groundwork, even if we haven't decided if/how to expose the > > > > > information to userspace. I'm happy to work up a patch while > > > > > the rest > > > > > of the discussion continues. I'm also happy to let someone > > > > > else work > > > > > up the patch, if anyone else is chomping at the bit ;). > > > > > > > > I am dubious on moving all of the user namespace members into > > > > ns_common. > > > > > > > > I would happy to be proved wrong but I suspect in the cases where > > > > we > > > > actually use that user namespace the code will become uglier. > > > > Making > > > > the ordinary uses uglier to make a rare corner case nicer is the > > > > wrong > > > > trade off. > > > > > > > > But feel free to try it is certainly worth doing if it doesn't > > > > make the > > > > code that uses the user namespaces uglier. > > > > > > If it's interesting for someone, I have this patch in my tree > > > https://github.com/avagin/linux-task-diag/commit/63b32df68ae8d3a384 > > > 2bae42bbcae3468db76d85 > > > > > > I can't say that it makes something uglier. > > > > I have only skimmed things but overall it looks better than I had > > feared. > > It looks about as messy as I feared, but since someone else has done > all the hard work, I'm happy. > > > At the same time I really really don't like losing the parent pointer > > in the user namespace case. That is seriously obfuscating. We can do something like this: @@ -27,11 +27,13 @@ struct user_namespace { ... - struct ns_common ns; + union { + struct user_namespace *parent; + struct ns_common ns; + }; unsigned long flags; ... @@ -97,6 +97,7 @@ int create_user_ns(struct cred *new) ... atomic_set(&ns->count, 1); /* Leave the new->user_ns reference with the new user namespace. */ + BUILD_BUG_ON(&ns->ns.user_ns != &ns->parent); ns->parent = parent_ns; > > Because it has a slightly different meaning from all other namespaces? > If I assume that's what you mean, I think looking at it in a different > way can solve the problem: The pointer in ns_common is always to the > owning user_ns, so we can label it as such. Even for a child user_ns, > the owning user_ns is simply the parent. I think it makes logical > sense to think of all user_ns to namespace relationships as > owning/owned rather than most as owning/owned and some as parent/child. I think we can rename ns.user_ns to ns.owner or ns.owner_ns. Thanks, Andrew > > James > > > Eric > > > > _______________________________________________ > > Containers mailing list > > Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > > https://lists.linuxfoundation.org/mailman/listinfo/containers > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753430AbcGKVJh (ORCPT ); Mon, 11 Jul 2016 17:09:37 -0400 Received: from mail-db5eur01on0106.outbound.protection.outlook.com ([104.47.2.106]:53270 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753285AbcGKVJf (ORCPT ); Mon, 11 Jul 2016 17:09:35 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Mon, 11 Jul 2016 13:55:00 -0700 From: Andrew Vagin To: James Bottomley CC: "Eric W. Biederman" , Linux API , Containers , lkml , , "Michael Kerrisk (man-pages)" Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Message-ID: <20160711205459.GA5026@outlook.office365.com> References: <20160706141348.GB20728@mail.hallyn.com> <20160707133631.GA2994@mail.hallyn.com> <1467903712.2347.16.camel@HansenPartnership.com> <20160709031528.GA25507@odin.tremily.us> <87ziprmrln.fsf@x220.int.ebiederm.org> <20160710053609.GB4868@outlook.office365.com> <87furhjkxw.fsf@x220.int.ebiederm.org> <1468184808.19833.30.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline In-Reply-To: <1468184808.19833.30.camel@HansenPartnership.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [162.246.95.100] X-ClientProxiedBy: BY2PR04CA0016.namprd04.prod.outlook.com (10.255.247.26) To AM5PR0801MB1972.eurprd08.prod.outlook.com (10.168.158.11) X-MS-Office365-Filtering-Correlation-Id: 05374e8f-113e-4cda-cec4-08d3a9cdac88 X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1972;2:BwFTYKy6HVcYto5DqnkUUFMIQzjSvFxixZ4PWazuIga/SgbN9nEtW90ofoN8E+jrv5PY8p2Y+lQKpK2vw45UJ8AUi0XrAo4O62svn7ngC8JvOfK4DqfuRrv0k6hHlBMAb4YYM3UKFFkwSzSrUfjr60FnoASwCqEIKKZXWDnB5tXschTQgRZTcnifa75vXGmm;3:yXWG8hHzfXKoXLfcuYorkRvmnrYEdhI3etgXIPrXCxMyFDe0Wn/f+70o0slqnSRT5BKURWTEVt36mp3DL79xX7fw5F3S6tQADEJQV/qz+8Eao34uxsH62ikHBBdbQqiK X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1972; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1972;25:Z4hFgTefCURi3l3shJRrMouRS7kLrv9SAgiUJ+9RPuLwfi7+HfRKzyV7HdEdM5tqPgRl9LAMtFY/zd9/VPoJWmc4GpkhunSK7DPGKhz0WURnG9shdu+hNZwdYauDaGdAUoPxV5fCjjXZw99LzV6MW/X3/OKc/lWglUgVUQ5z9LFbSGyNfBIYf29Ta9eXdOa9eAhGRb34B3z2tktfdy6JYh/44AnkVGkMizA+cV2cCgxNfnoyzcMs6RSvMsl6MV+/EGrKTZrSp75bfzucIFtXMXxQAda25i9gAAKRfZ8HTwkH6Z2N0FnMxnwZ3+gTMEmb2iealsCDvgfdWUi770+HcVd/l2ol26HI18iMfxFS2PK+ywN6nRbMkc1wfIGlH2Z66GIyfUvRYUt7TcVcKQWr0daZPXBCW40PrAbK8SoOBTtg7eglmY3tH4Dg9oTfJU413RQri4CZHCwnd5oHpx2/hCKF6ZN0SzDaFurSvwYvCy33EUge+PlKzCboMi130Db+GX25ep5T5x39TsnVfl5zzVGSR/+3gYJLxHKnpEjwdxYsfBf0dRKwqCNawdArS7f2u2xhGQDuIWdDlMG4NRyyB872Rq6p15gTGrslBTi+PTX+OVwYh9mFuHt2cjwD8ouOSJ6+0apyX57827Iy0zQC9zpkdV06NRamwjRDcvd9ndftTRTK/NB6mLTV8b0XYNKMRjNfE3/JobIdtcPKW2IgCj2BkmP1uepr56xtlNBXtlBUD+qttMkq2dUhEX31TwLzP7ah3zCBfma3lPjSkkVzynmgNfJopcXUYn5CkGPC7PxLKpy77ouF42bw9IfphgF//olA3IyflPsuhMzL7yp63WaBeF6l8DhVfSKOl+5kbhk= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1972;31:zxh4Ce+F2tvZ3Ic4G+MYLnGXkGaM8Hscz4dZgqcVetdIriG+JDBYdVxVsm3QgoWNsJlHtGHpap10roXkpytQNjFBDORh4iIjgXYD6O5ZuLebjPG1KzTdAh1vldIPbfZzDA8TGkpvkk7sXEAUZH8IE5hjE+t97f7aTtnryjlt7AgJzf18j/nZ3UUCuIfIeg67brKUKuVp7OlzG7UNNvcIhA==;4:P8HkHHObFOgqOjxjbIv2hXyuTyoCCgj688f9oKqLg4IeYVKg8aCoZygu9tWa9ye0vMr+vxweceRNGsy8A3uSiBtz3NFZRfEw6TNT0yoc7bS5vJyVFsoXX0pao0NACF3ETevOWkwOOjoV7Y1JLX7ZqCWE5mnrvb+xfQHf0xx+ezxoDNBa8MWc8IhjAdvVgEvgNWv1bPg7aQdpYyxjq/O5KBg4p3sCJdrDvP+76GhoHeEmeQY1RTrCivRajFCRBhfkPEdaRIB9GuQWt5xHHDX/luvtsD5Frw+phbAOXbn2TbWuOfQ6vD1aN22Msr2IBfRibf5ZPz0F968ezs7EOJa/u/oHpDAZxqdp1lTvPUUnNg5bgFFEJk5wrSBIpcHLUi/dQkIxUmFOWxvpJx6L+M2U826usQp2Q25pcwCvztHlIQPZBtGUG7o+RXUppC8ulsqDF5KTMOlabRda3r9nS/WYTw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:AM5PR0801MB1972;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1972; X-Forefront-PRVS: 00003DBFE7 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(24454002)(189002)(377424004)(52044002)(110136002)(68736007)(8676002)(189998001)(97736004)(50466002)(23686003)(33656002)(69596002)(106356001)(81156014)(19580405001)(19580395003)(81166006)(92566002)(4001350100001)(9686002)(47776003)(2950100001)(2906002)(1076002)(66066001)(6116002)(3846002)(586003)(305945005)(4326007)(7736002)(7846002)(54356999)(93886004)(76176999)(105586002)(15975445007)(42186005)(77096005)(83506001)(86362001)(53416004)(101416001)(50986999)(7099028)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1972;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;AM5PR0801MB1972;23:YsOFzqgaTBsgBVooyE83zlQDdhcJ5GBpviP8SwK3b?= =?koi8-r?Q?3o455V41+bMz7UureSdmyKQuOIzYo6Ak6OY0AF2diycoO+BENz5OBafpmU97uo?= =?koi8-r?Q?LPDoNwHoXFKiLbLN8TdQVF6b8tbke2UO0ztx3rXat+fXarfIBnza3CbAnU7uYB?= =?koi8-r?Q?a3dnawqjd2L8NAb7zgAEmiytJpFliXt0zEotgxXnujvJKhcDG9N50WGPH/1DUb?= =?koi8-r?Q?vOQZ58R5md00FswA0ASslxGg4boiH8KfzzMKYypuwIXw5Gw4ZH4jDOOsH8AkHK?= =?koi8-r?Q?HCxOyUHRBor48N2UJcpEG4hwzdQ4q4Ynhd6E9u3RIAQn2nMc1QFVDYDRms+sZB?= =?koi8-r?Q?LiVr+Jwo2jcUIEn0dV21zkYm9UkiMjNjWzZdxOgXlIBnLyYsvhWl6GhUzdj90v?= =?koi8-r?Q?ZVY+IlxQo+c7yXmQouYsnFH+Jr3J69/fkQzBzRseFsFOmPXtBuvxVeQ1yFyXZ8?= =?koi8-r?Q?UEUeNtyQoLts/sCDbNrEqSzC+4RDwAbsdnM2UeT9Jc7GJtzI0cIl+l6WhxRB1y?= =?koi8-r?Q?OH2ZmFnNuuVdgfDAR/gTvBLHZ4MUEV/oBbES/AJYk9fXEtQt0Wx6hzkqcfaw8N?= =?koi8-r?Q?2OCb/nu7P9fIjwQ0ejd4y3E1xx3M6xcLsM92hK1r96kY2NUL6gnAAy9Fv+LqgY?= =?koi8-r?Q?SOdFtOWYfvd6QkZ2axJfKNCCW518vpl14HJQhZxaaaXAopjsX11buxEGX0YN6q?= =?koi8-r?Q?VpN+6zzrUXHCUMf1oetFgM+9/UOIRTGEDsMq0FSX/vy/LBjISSy6OrQgNjKIgH?= =?koi8-r?Q?0+TTug8saxMOssuzkIphnINsQ4U9ii3EZfeZRmjBzChnA4dQcpnptL+c+tHgPM?= =?koi8-r?Q?heNgECLyMfL+xG6uRY9ZvNmYPuUDAIvtZLWApKVjnCHknHuMQqy60APdpBx4et?= =?koi8-r?Q?hqKjo10BUGw7XM12KGFVdokAwjllB948ktmdgRMyr/qr+rEvv2gdS6MI6wcIA/?= =?koi8-r?Q?HGkmQIrb0EkLPjoQsTRDRljgo/nOYXa9b/9FHheQfm/Z55/jqLu5H+iHb7tAmd?= =?koi8-r?Q?Yg5TGpnvMtxWJfmm/aPQ1Iy58bRKtZj0Rg7fUCDGzeXeTX8HrtO23RZYyTxZ9K?= =?koi8-r?Q?IRvxLodvtmU1j4816VBMSLl9b97/1HTnFHyjGL6wSu/272AOHv2OM06jZAqvZw?= =?koi8-r?Q?GOjV2AZOw/K1nHai/E0+ATDwTqrrs1dZlooZeFVSkWZR4nxb9I0PZ2M9ECbR1L?= =?koi8-r?Q?VcENaMfFB1FLgh8lGvYlzATgXVhr5XnFdLCixfW/WJxguXVvJgONAzH4CpQCw2?= =?koi8-r?Q?Z2bAEgqU9SBPjDRPlpZfw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1972;6:C/rn8lvPf/zzRNrZmANEtI5YmgfcS7FkBCaqyNungOQ7NKg5nd07xqosRAJ0FloEYAvoVHS92vmVK0jJLSMdGCrUETMY/zl3x79jfEN8k6NUHjkgfTny3SP1PDDQt3qf1nPps+wujkaGqAf66XpNXu6IBsvmLH3NvVv+yn47xVM+LqPReI/YChF2Vb0/1FWoX/iLDJBuN+1jPDZWfoke88aP3tkpN3cSd2MFaP6emAmo5x0vFYOJc4giwgZBvBFUqVry1s04oTX+HfUazXHRUscmjlfK1xo+FYIguYpLAr1kGzcSNP2N2LFov2yyR9WM;5:bds9//ZlEfJWIjzJULNjDqFoM2qbQ2xfgw3d8mZF4flTYpv+6o2JGCDoeEZNOLLM465tlg9j443PWc1jXs4HWPmdrwr88T5xQIGtA8K5Qy+VzM294Mjnjb2cZ8YOKRVbeDBKlDlkfN2tXGI9fLftdA==;24:F4uuzUEtOL7BKBjfPLWuirjJuy+XjVRxGQ3tru8/cXDbKkhFCJJJVE2MKW+MKXbbS3xDm/Rwo5q4Rea12/wTgagoFikRwCv/itUE3BAU1WM=;7:DpzFkFfCiQAJxxZikDbsy0YoZ9q9v9MzVEDoS+5YY9Oaa81pvoq1HnWNyIGqGM8D7TNnuK4ZGUGIbyU4sL2iGnvmroXZefFH5rpKd0+cTlDh5hxXfPom9rr5v7WZb/GGoSnoTRTjcxzUesiYurrWVqDVgeFRNpTNvxTQvdxoKPKY6NhpV6EJ6NuBIPNmJE8Ano9PDExEhF7WHJfwHRLBJFcDIPg1IhO0Qcw0mT3i+Q9CHBee8NkEXhJx5BnUIe19 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1972;20:zZr+5mChkz2QDhpC2o572Z6t7VTnNvCLOHEB9LdzN4cFKtC68vCDuIf5LJTSePj30OOUrjdkOBOyVElYziK5Kpzvj7x5lWvGqHLP2IL94E9FWp5fmocJXfxLztb2ZN4z/ejkm6VWTi/ZgN5Pf4ptrfzQO5iL9jzZha2vYFkSVck= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2016 20:55:20.2466 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1972 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 11, 2016 at 06:06:48AM +0900, James Bottomley wrote: > On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote: > > Andrew Vagin writes: > > > > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: > > > > "W. Trevor King" writes: > > > > > > > > > On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley > > > > > wrote: > > > > > > 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 reasonably large > > > > > > (but > > > > > > mechanical) change. > > > > > > > > > > It sounds like everyone is either positive or or neutral on > > > > > this > > > > > groundwork, even if we haven't decided if/how to expose the > > > > > information to userspace. I'm happy to work up a patch while > > > > > the rest > > > > > of the discussion continues. I'm also happy to let someone > > > > > else work > > > > > up the patch, if anyone else is chomping at the bit ;). > > > > > > > > I am dubious on moving all of the user namespace members into > > > > ns_common. > > > > > > > > I would happy to be proved wrong but I suspect in the cases where > > > > we > > > > actually use that user namespace the code will become uglier. > > > > Making > > > > the ordinary uses uglier to make a rare corner case nicer is the > > > > wrong > > > > trade off. > > > > > > > > But feel free to try it is certainly worth doing if it doesn't > > > > make the > > > > code that uses the user namespaces uglier. > > > > > > If it's interesting for someone, I have this patch in my tree > > > https://github.com/avagin/linux-task-diag/commit/63b32df68ae8d3a384 > > > 2bae42bbcae3468db76d85 > > > > > > I can't say that it makes something uglier. > > > > I have only skimmed things but overall it looks better than I had > > feared. > > It looks about as messy as I feared, but since someone else has done > all the hard work, I'm happy. > > > At the same time I really really don't like losing the parent pointer > > in the user namespace case. That is seriously obfuscating. We can do something like this: @@ -27,11 +27,13 @@ struct user_namespace { ... - struct ns_common ns; + union { + struct user_namespace *parent; + struct ns_common ns; + }; unsigned long flags; ... @@ -97,6 +97,7 @@ int create_user_ns(struct cred *new) ... atomic_set(&ns->count, 1); /* Leave the new->user_ns reference with the new user namespace. */ + BUILD_BUG_ON(&ns->ns.user_ns != &ns->parent); ns->parent = parent_ns; > > Because it has a slightly different meaning from all other namespaces? > If I assume that's what you mean, I think looking at it in a different > way can solve the problem: The pointer in ns_common is always to the > owning user_ns, so we can label it as such. Even for a child user_ns, > the owning user_ns is simply the parent. I think it makes logical > sense to think of all user_ns to namespace relationships as > owning/owned rather than most as owning/owned and some as parent/child. I think we can rename ns.user_ns to ns.owner or ns.owner_ns. Thanks, Andrew > > James > > > Eric > > > > _______________________________________________ > > Containers mailing list > > Containers@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/containers > > >