From: Laurent Vivier <laurent@vivier.eu>
To: Eric Biederman <ebiederm@xmission.com>
Cc: Andrei Vagin <avagin@gmail.com>,
linux-kernel@vger.kernel.org, Jann Horn <jannh@google.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
containers@lists.linux-foundation.org,
Dmitry Safonov <dima@arista.com>
Subject: Re: [PATCH v6 1/1] ns: add binfmt_misc to the user namespace
Date: Tue, 30 Oct 2018 09:51:30 +0100 [thread overview]
Message-ID: <4a1ec0cf-dce7-4193-6946-d46d63398c2d@vivier.eu> (raw)
In-Reply-To: <0fb09ce6-e006-31a2-1f32-f3f6eda44504@vivier.eu>
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 <laurent@vivier.eu>
>>
>> Acked-by: Andrei Vagin <avagin@gmail.com>
>>
>> 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
next prev parent reply other threads:[~2018-10-30 8:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 16:14 [PATCH v6 0/1] ns: introduce binfmt_misc namespace Laurent Vivier
2018-10-10 16:14 ` [PATCH v6 1/1] ns: add binfmt_misc to the user namespace Laurent Vivier
2018-10-16 10:13 ` Rasmus Villemoes
2018-10-16 10:53 ` Laurent Vivier
2018-10-16 16:22 ` Andrei Vagin
2018-10-24 17:15 ` Laurent Vivier
2018-10-30 8:51 ` Laurent Vivier [this message]
2018-11-06 19:40 ` Jann Horn
2018-10-16 9:52 ` [PATCH v6 0/1] ns: introduce binfmt_misc namespace Laurent Vivier
2018-11-01 2:59 ` James Bottomley
2018-11-01 3:51 ` Jann Horn
2018-11-01 12:28 ` Laurent Vivier
2018-11-01 14:16 ` Eric W. Biederman
2018-11-29 13:05 ` Laurent Vivier
2018-12-29 15:41 ` Laurent Vivier
2018-11-01 14:10 ` James Bottomley
2018-11-01 14:44 ` Jann Horn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a1ec0cf-dce7-4193-6946-d46d63398c2d@vivier.eu \
--to=laurent@vivier.eu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=avagin@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=dima@arista.com \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).