From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751801AbcGMDn4 (ORCPT ); Tue, 12 Jul 2016 23:43:56 -0400 Received: from mail-db5eur01on0099.outbound.protection.outlook.com ([104.47.2.99]:17584 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750941AbcGMDnu (ORCPT ); Tue, 12 Jul 2016 23:43:50 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Date: Tue, 12 Jul 2016 17:08:43 -0700 From: Andrew Vagin To: "Eric W. Biederman" , James Bottomley , "W. Trevor King" , "Michael Kerrisk (man-pages)" CC: Linux API , Containers , lkml , Subject: Re: [CRIU] Introspecting userns relationships to other namespaces? Message-ID: <20160713000842.GC5818@outlook.office365.com> References: <87vb0gy3nr.fsf@x220.int.ebiederm.org> <1467988533.2322.118.camel@HansenPartnership.com> <20160708203818.GA2602@outlook.office365.com> <5e4cc802-f0e0-4f4c-a2f7-585aaaa8feec@email.android.com> <87wpkvpu1i.fsf@x220.int.ebiederm.org> <1468023332.2390.10.camel@HansenPartnership.com> <87bn27o6j5.fsf@x220.int.ebiederm.org> <20160709072627.GA7480@outlook.office365.com> <87eg72llu0.fsf@x220.int.ebiederm.org> <871t32ll6n.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Disposition: inline In-Reply-To: <871t32ll6n.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [162.246.95.100] X-ClientProxiedBy: BLUPR11CA0011.namprd11.prod.outlook.com (10.141.240.21) To VI1PR0801MB1982.eurprd08.prod.outlook.com (10.173.74.15) X-MS-Office365-Filtering-Correlation-Id: af32c733-4663-4f7b-f03c-08d3aab1e29d X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1982;2:zAQpB6GmhCFfdcu2Q5wWzXaDpMy0eJAulO8PNP/91Vq/C+hx5QQ1X22RlJyf7rcOQgv3Gq7FgE5KL2HxHVY+weZWc78sHpJkJpSFftARvBc9ihNUBqxWgWoABcLkzv/yagr+B8AJkgdxJix1x/FHcdN0xAnVRIHJsFwLbyffP02w47QkJnZvMkR2bDjc34mw;3:0wbD5nyY8UtlXSy840cp4ou1DG0dBKr8Hver75IGtDcZx7HAynJLmnjgMZflFc4dWg/2GnwVr1GGIXkGSTObceL9KXjNfomnkrqlANFRKmP5lClciLFG2SxOyFWxJ854 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1982; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1982;25:yQ3QxWjTsiEnqVmyCCVQw2SJ+Fh8l31l3npWDtl2cWBUPwjOq5iC79CZM2aAvAmeEjEn0Qh5q1QwIshx5ZisNgGqMYL0o0dHCdciQ1CLVAiMTMKK7N6/VoViqPWGh2RSiYaPZ6d3e+1LZXjz5k5+k1YbGhqFspKGGeF9Ku1j+QPMZfIhcyzo+Zih4lJr5jCs4TiixrCSMHYX8UwJOORqcIID5Lara3mTzb+Ht+Y3dEyxq7NblhaljuEvMKNzFmjfhknF0bLEYuIA/UQxMoAdMQiKohzdHRjC1ieOyUMV3kXlphTPn8IaqeAQH+JU6Lk+LnJpurcP8NV6moeYlL3Cy/uKZdHDRxz7c2mkgEobQ8wTyKIy3lItmXSZlSSaw3gGl/wzFATzVvrf9x2uszAQzmZLZtqmkGx9TshuixmpL9HtQtGU8azP284H8FbUpvEE6wiFwe1EFBGEUz+8uIg3ki2y0GFN98A/iXnHnnr0tQcUM4QDrD5LXSDkv95IdjZlcG0CJKGlKp3m2V7bpxnviFjx7GP4nwDc3a7Csz+roHxdUV7Tg4ibK3m8Lmb7eLOa5Fw4v1W2At6XV9GgsKQKALWSKueLpwOPrLfeL2dhwKCHpLiywcO+Y35pZw6ur3+Dl7xJZn+b/giyYljvS/7mkekdGII6+sAr7x5fQs4/PwRK7F/+KU0x+eb8Zz2L08puVeIA1pEywOW2UaOYaenKTwxegMxWjKG71EntypaOlG/0d319GIoav3BqhvgDAs/oOdyK7aYtRSyUASziKJvl2p2wotrXO2mU3pOrSTpiTuyqmbr/pSeRbv+Igw4zH5MjNmOf7ibOJqiv0nXmAgxSI5t7aaP0rLmexCCPHAWTMDpA6AZdmZ9U8+j6l1cBBIzi X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1982;31:X/TpOxlzKIvRQIZHodVfvb1D2xROAJdSnYYTTZGRRNoa6aRgH8qM4XL0znhbmyb8a30zroag/5ggVt1UmxOy+D2xqebzApaSrLXChJv62HtUcraij1FWaRyPIAJUFnYxXaq9KE/pZIjt7tWNpPjJR3YNAFYhZvTTTNDHHpINOww3zkh+jPI6mJRl8l3wXZTuAodvjqMXOfK3uT/8B86VFw==;4:/w/vFDS5kvRPmd8IFFfdadpwLpSX8RgXRKsBVHgDxm0gQEs/nykHaB9bqAZN5HZL5bGc3FYbq/TSNe9vXK5svqNKYcXeft4SQXAHRQYNzh5HnR/vcPjUB7BooDWa3w8hfwpiinuTv8Y6C56wAIAgSh7WTJOcxMbK7Cuyqt0SCl2UAQFm/LfGrhm8XS1PYMBlVL82JfPDwJshdfU+0Vf2dcyQnnXJDN27w305JE1CgDGuaWMXtD9V3PBur2HFKjaUShjiV5KmvZAZFd4/2QUmF0gaoQIDyNHVGndMDB0ZTGaysUnLcBtfsMT04n2r5HrnkCJqRm6JHpo8aIfV9swE5fYJuadnrQz0GgJyrYqL3q9ClC7pTX/x+VT8B8xpvPeBmIjYmLVRNKRNGdtLwuCZ/mwEtWNVluc/jh/PyhmSL1gDbjqrh0LpLimieofgeJfl3azzSzJ+PpsJ5br4Vy0eFRh1AcP40wsnm+d+s1urzCilD3DbDoRr1v0VZsYolS4P X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:VI1PR0801MB1982;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1982; X-Forefront-PRVS: 000227DA0C X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(24454002)(19580405001)(19580395003)(92566002)(83506001)(33656002)(2950100001)(53416004)(4001430100002)(69596002)(93886004)(2906002)(42186005)(4326007)(86362001)(101416001)(3846002)(586003)(6116002)(23686003)(1076002)(575784001)(9686002)(8676002)(76176999)(50986999)(106356001)(54356999)(47776003)(68736007)(4001350100001)(66066001)(105586002)(81156014)(7736002)(7846002)(97736004)(107886002)(189998001)(50466002)(305945005)(15975445007)(77096005)(81166006)(5001770100001)(7099028)(18370500001)(26326002);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1982;H:outlook.office365.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;VI1PR0801MB1982;23:t8OLzh2jQ1toYPMh7Z3du3g0bCKd1UQL+wLg0JJFk?= =?koi8-r?Q?kodwW2e/PrqAnlc3JZGBnVVayVHHuWFSkUywD0oIhkQmBK4FGnRrSvWUkT/oYF?= =?koi8-r?Q?e8YnPaTF24nB2kzKYnisE6c/OM9eGTqwf/Jl6nm+qymghXNOORj6ia9eOuGt/6?= =?koi8-r?Q?xCB8lQNdwPnPeu8FQKPo9K9kCilQCB+jqWEZa3xYfk8RQtgDn3PIRO8LITH90u?= =?koi8-r?Q?FwVWJyDhL2JgeR1RqeNkD+zcyEbL725QrurDbzsWCHgHHT1fujlMpY8VLYSN7T?= =?koi8-r?Q?xBGzVfNLrY4urt+JfheUFubCocLcwEjyWKv0ulQkP52/AZ8/9xCwCP3cydQaT9?= =?koi8-r?Q?6CwCYH1qMzd8tRfX7dFm4FYQXs/wSjs5eP8xmBe95IssuyZ3OvQlhm8OWLPFCh?= =?koi8-r?Q?gTn5yDg8/eIru6Vb8Xmo+FOnRNuLniX6CTS/Bh1+S1YsBhBTqps+6N5N80yc2A?= =?koi8-r?Q?aCYnYGP0wa8u/LSZTqPCckCpFbFVrcFCdVP0s82/A237AlCqRxFMhdotLFrTJn?= =?koi8-r?Q?3gLNDyfQ0+TiXpBQ0/kNJXLTE39VPHjwzSarG4C7dJoXOIXZ1OgnCNIeZnNs5u?= =?koi8-r?Q?292BDLvlVluIAs5kx4n3vYQtZiw/T/yPPf/FbIRzWuAPBDLV/oQMjnTtpnIKVO?= =?koi8-r?Q?r/f68BG8JP2wieNbyduXIj46YmfsAWghI/803ji+8au0AbRYzWVjqBguyll/YQ?= =?koi8-r?Q?0HaFtvKQQhRA2qrZUIhWl4q0RUrm94HeukoB9wZXbC+PhDlBzvrfTN6aNrLKiN?= =?koi8-r?Q?e0R6taZ2yNptIAOHcKmXseLuRa6K2f2sbCXqDqUDJiLSddeweOq8ONtpq0FGca?= =?koi8-r?Q?lBdDZaP2MYYYBAml/AD7mtiSoTq/2NP8mycrVixXbEdb/H2L8kIRcBhBgUdNaZ?= =?koi8-r?Q?MTllu/Mp+ZI/zI+j8vJW0v68pw7Tfh0xGdhWRXt5WEwTrauNGBg67fdfMomgT6?= =?koi8-r?Q?FbDM+xs6x1yqCVuIrKgynOIoy207BLFRbJ6PcHHntoscCJI4Gk3UyETB58ZCCH?= =?koi8-r?Q?661FINMZVco8brXeEnj1+uC2fUxdibAykebI12IOprs3Hc0WMTfF1/JtBEq+Rl?= =?koi8-r?Q?o5YxRQiQXn3Bf+HkxUxNjA9zfttGlwxggAVl5l+MwicqLARpokhlrtmp1++nKA?= =?koi8-r?Q?sn5ymOSzZznLEllLM9ZqNe2HMdMYP9mnXbq5qu7kwf8G9tQvpSWwbC++L1GMXD?= =?koi8-r?Q?+rjfL5pX7KtIWA9OjH3HHszc5Ymi7nZtrkirFEjTa4uaFTeduJM526pUYNTxA0?= =?koi8-r?Q?tNJ1TDwNEyyWQL81+E1hGhmsue0VeHkVNddFclfD/CgfRogwqru9P/HF/eaa2u?= =?koi8-r?Q?N?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1982;6:F1/rkyIntu+VevUJpxRJJykdmlPwo+BOsdCJKNJlsDoa+1bySfQ/mDy60l/EABwlXFHnNoi9XSWF0ND7rHd/ZRsu4H/w7B9lqcMcOThFnn5teLgkppCNpLVcRXXzBay0ZCfVuaDuV/DGrgOIOZOpM60kaSzNiGNQQKTzjR0Lp0zc+UtbM/EeRX4ppKDfnSSRpgjLrLOmwrVeGQj7/sy+6LZljVg4vpAZeTG36ch5iGManlJKMdICUE3z068FbTVLqICviYqmBAm7dGwklzFBBvLiqd8ITrhHayGEGK6K2B2ZGx5KQXEKEMdbVwdAteyB;5:OVI/Htm3gBqwxOy3tynA1M7z871xUrDSZLyJMO5feJqCuxAcuR6MUQA3fX5Poatvyaeg2KE9MvhMFgimH3YfvLHyvKR6GSmtTNVLgAOUZwArsRF7xFm7Gw8fwMgluDnM4EH03lGIMd1wMldyeG/m7A==;24:iT4FhL42LmzPpqfYuBzd1xvf4OAi0F8aUoWhCIqBKi0suJC1aYZQD26nEGG7z1R4O7dGqpdNGP12Esq6/PHLiupJS4/pRy9Za4A+LRlSw1s=;7:BFuONDq5heHlSLvsoWpFRrD8En9S6d0hKcFdd9bwVbN6xLDtxFfVDWt8CWh9+oh+AyQ3W2e1Eh6RLHWUcZTnVonIqjMDiFaFCxU6LzWH8NGZCDsisGqfkWZGVHXE3wC3IKyrLk8WVAAuScGdhsVjBQrwOGJWSm8/0bCXYQOPOseW7/U9jOXdMKceQ2h6eWEas8gW9x6yZeZvXjmNUiHQsLdu82iLis64rd8uFI6GVcXldwKEqI07+dbqxM5nOU8Z SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1982;20:fx72rqSdwMq7CYgTfz75CBrASKQ8V633iQ16+j0z97Uqt/QRBllH36aqCTjfILbX0GQtY7ZlGRHn16Pl8Oaplvqr1XQ1LIbwgHXgyrDHREtbV8GIS/a0f6QOnouUbbetoSAXiP/cVsjWcl9eupJvEBLOGEUmZo/PjdC74teq86E= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jul 2016 00:08:55.8861 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1982 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 09, 2016 at 01:29:20PM -0500, Eric W. Biederman wrote: > ebiederm@xmission.com (Eric W. Biederman) writes: > > > Andrew Vagin writes: > > > >> All these thoughts about security make me thinking that kcmp is what we > >> should use here. It's maybe something like this: > >> > >> kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2) > >> > >> - to check if userns of the fd1 namepsace is equal to the fd2 userns > >> > >> kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2) > >> > >> - to check if a parent namespace of the fd1 pidns is equal to fd pidns. > >> > >> fd1 and fd2 is file descriptors to namespace files. > >> > >> So if we want to build a hierarchy, we need to collect all namespaces > >> and then enumerate them to check dependencies with help of kcmp. > > > > That is certainly one way to go. > > > > There is a funny case where we would want to compare a user namespace > > file descriptor to a parent user namespace file descriptor. > > > > > > Grumble, Grumble. I think this may actually a case for creating ioctls > > for these two cases. Now that random nsfs file descriptors are bind > > mountable the original reason for using proc files is not as pressing. > > > > One ioctl for the user namespace that owns a file descriptor. > > One ioctl for the parent namespace of a namespace file descriptor. > > > > We also need some way to get a command file descriptor for a file system > > super block. Al Viro has a pet project for cleaning up the mount API > > and this might be the idea excuse to start looking at that. > > > > (In principle we might be able to run commands through the namespace > > file descriptor and using an ioctl feels dirty. But an ioctl that > > only uses the fd and request argument does not suffer from the same > > problems that ioctls that have to pass additional arguments suffer > > from.) > > Of course it should be an error perhaps -EINVAL to get a user > namespace owner or parent namespace that is outside of a processes > current user namespace or pid namespace. That way thing stay bounded > within the current namespaces the process is in. Which prevents any > leak possibilities, and keeps CRIU working. I prepared patches with ioctl-s to understand how it looks like. Here is a whole series: https://github.com/avagin/linux-task-diag/commits/namespaces Here is a patch to get an owning user namespace: https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238 https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088 Here is an example how it looks from user-space: https://github.com/avagin/linux-task-diag/blob/namespaces/tools/testing/selftests/nsfs/owner.c#L49 I like the idea with ioctl-s. James, Michael, Trevor, what is your opinion about this? > > Eric