Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4442275imd; Tue, 30 Oct 2018 01:54:06 -0700 (PDT) X-Google-Smtp-Source: AJdET5dtTYkx+qiKuiVjGnw+Okc9Y7GLJx14VyFecaY/1lsvujwJH/VNZgINALcYDo2WI7keu3Ou X-Received: by 2002:a62:1803:: with SMTP id 3-v6mr2038979pfy.21.1540889646508; Tue, 30 Oct 2018 01:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540889646; cv=none; d=google.com; s=arc-20160816; b=Tl2uFqFj3Hf+AYVa+DEMXwPU/ftzUHiL7O49YemtY93Ohy11B7zGhwGHH8gQ1jKS6S zwbDIzlp6ELy8vJ6cVKPTJM2iZzLAnOLC21Qw0PKUML78yZ72MMcJej9AFLxN2/VpVOd 9qkU3ksQO9BiCoCDzSM16Wqm1RlShKz+XSnqu5JEtZ3cztCD7r5nsI3+yOtRb9kx7evx CFZJTIQ4WWnB8FARI8NfQBgWRMmguf7dMOxxvKo8M7AV7l+lHqK045jVGoGQzpKS6ELX l1H02MoEky3EEE83mIryGbSILpPcYAZh2C+dbzX5fOL8L8CAPezOvXNFiLsHvJOfR3LA /xYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=F3K6Fb5Q73HX6T2ebVfcUTeXzx68p6z4xxpfF9OSrg8=; b=Pt+iPGqfByQ6NqxobQVWC2biADRID6gvS61kgheAAyOFL+2y5/2X5b22D4RPsABhJc S6LpWTI1y49q9JCSXd1ZhDVGpRbwKSM1jwBZZHHoBvColx1ffjoE7XN4DLCdEIQ1lTy5 kNUhLL95CmpJuQwdbXLUJh+kT1YFkVYdPR0nGSS0WOb09krfVh12VffiyzzI2K9NTR3t 96gLeWi9EmAqKeDjB/O1GlZ7l+/4WYARgjrsXGJXYNgTbHYQZmd4smrDX/1SQrSrUbwS BZZJRh74DVHsrdeoWwWMkONnbqPnQ/sU5ze9RDjBUvIOBYANCL9EQXE7mstsxNXsSvam q75A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g86-v6si30143044pfa.285.2018.10.30.01.53.50; Tue, 30 Oct 2018 01:54:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726908AbeJ3Roh (ORCPT + 99 others); Tue, 30 Oct 2018 13:44:37 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:49769 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726225AbeJ3Roh (ORCPT ); Tue, 30 Oct 2018 13:44:37 -0400 Received: from [192.168.100.1] ([78.238.229.36]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MI5YN-1gNl0T3Bjz-00F9I0; Tue, 30 Oct 2018 09:51:34 +0100 Received: from [192.168.100.1] ([78.238.229.36]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MI5YN-1gNl0T3Bjz-00F9I0; Tue, 30 Oct 2018 09:51:34 +0100 Subject: Re: [PATCH v6 1/1] ns: add binfmt_misc to the user namespace From: Laurent Vivier To: Eric Biederman Cc: Andrei Vagin , linux-kernel@vger.kernel.org, Jann Horn , James Bottomley , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, Alexander Viro , containers@lists.linux-foundation.org, Dmitry Safonov References: <20181010161430.11633-1-laurent@vivier.eu> <20181010161430.11633-2-laurent@vivier.eu> <20181016162245.GA7697@gmail.com> <0fb09ce6-e006-31a2-1f32-f3f6eda44504@vivier.eu> Message-ID: <4a1ec0cf-dce7-4193-6946-d46d63398c2d@vivier.eu> Date: Tue, 30 Oct 2018 09:51:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0fb09ce6-e006-31a2-1f32-f3f6eda44504@vivier.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:3gFO3SVwnxgIr3iwSd86bsSaiXl3McEQmHvEzfX8QQXsr6VUzg0 FkHA7Nx5zDh6cDONU+IpbbgHaLJms/zb/bNJPrK6cr2voosxmWW7+YrOzio/7oeNn3ZtI2j mU2g3z6rqABthGVue9FmzIb2cjBe+jAYIdQ4S5wX7QNKMZrfoQLMrAnbYR+MgobVEJ1XeMc z34dSAynvhxhOVjbKUP+Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V01:K0:3wNgsPBuC2I=:Ege9K4+ttZK0gTOjYCKFvv x6QiIIAAvqbgIL7aSWrIAi6WFFfuxiwpYnoh4Oyi+k/o0z35GNbBxcp9VUVmmTpQ5aLjfZzsd mTxiM0RJ/y/Vf/JUzw5xZSJsKoT9YxpSNvd0Zkz6JDAzA/8XlR8791To+AKE6VXlMGSkgPp7z F3uvrLM8h8cs4R6RXIvPmcuK5F/eltH+GkGB9MUFVuqih/Q+95bKyzw+tbATHX2voWRCbYNcl BjSwc//yMffSO9EzbDSBwi5w54cuURy1w+wYQ4yr0OTFBmQAzbTNSQ3y8PdGnP592tIYlghFd zZP/d0I0wfWKbfRrPXI4d0iyZoaqhh8I2z+jmaYZM38nKP11VsXzeAG3BNKy6hI3f8syP5tWB vOwNjp9sXoeFIaWEUucPd2VdmmZWj9pojyxpLiXvgmlXCj6FYPHegKcPvmaLoVmDs3EC1ji2N yddjkUjQUrITx2E/0vG1b2eElDZc5WaOR77R3gOA2FGxOK8xq+YwrX/ZtDdvVl3Exrmm9ksoX PXugw8joTAev/0CS673jhOwXsB54cAX8gqBq2EyBhVgQ4XRBU5rSQX6AMd0QJtnwgXW/pOgzh SEWp3OoQEXwdkUhTrsaGfJEuMaAOwmBtGQdKugcOdf10IUGw8BV5+qF4SY65w5m7blCHZCBhJ vgVfixGpwEN7VRBUVZlz+v1KtPS2fm2eRotmRCMP2nkj+h+8Fs4URuPpdE6mQ1Fj+74cYBdaU OdmY0uHi8CfzxRMA Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 24/10/2018 à 19:15, Laurent Vivier a écrit : > On 16/10/2018 17:22, Andrei Vagin wrote: >> On Wed, Oct 10, 2018 at 06:14:30PM +0200, Laurent Vivier wrote: >>> This patch allows to have a different binfmt_misc configuration >>> for each new user namespace. By default, the binfmt_misc configuration >>> is the one of the previous level, but if the binfmt_misc filesystem is >>> mounted in the new namespace a new empty binfmt instance is created and >>> used in this namespace. >>> >>> For instance, using "unshare" we can start a chroot of another >>> architecture and configure the binfmt_misc interpreter without being root >>> to run the binaries in this chroot. >>> >>> Signed-off-by: Laurent Vivier >> >> Acked-by: Andrei Vagin >> >> Thanks, >> Andrei >> > > I don't konw who is the maintainer for this part, but is there any > chance to have this merged in 4.20? > I'd really want to have this merged. I have some real use cases for this: 1- to allow a non root user to run a container (with "unshare" for instance) with its own binfmt_misc configuration. For instance, like we provide a disk image and ask an ordinary user to run it with his favorite VM hypervisor, we can provide a tar.gz containing our own interpreter and just ask him to unshare+chroot to the exploded file tree, 2- to allow to run automatic tests of an interpreter on a machine without having to change the global configuration of the system. I have in mind to add some tests in Avocado to automatically test qemu-linux-user in containers, so the interpreter path can depend on the build path and possibly run them concurrently, 3- to select an interpreter by container. For instance, on the qemu-devel mailing list, we have a waiting patch to add the bFLT interpreter binfmt_misc configuration, but the bFLT doesn't provide the CPU type in magic/mask. So it would be interesting to be able to select also a bFLT interpreter by container, as we know the CPU architecture we have in each chroot/container, 4- another example to select an interpreter by container is qemu-mips and qemu-misn32 share the same magic/mask because only the kernel API changes, so we can't configure both on the system (but I agree it's a QEMU bug: they should be merged and the kernel API be selected at runtime). Thanks, Laurent