On 25/03/2021 19:24, Michael Tokarev wrote:
> 25.03.2021 16:33, Silvano Cirujano Cuesta wrote:
>> Package: qemu-user-static
>> Version: 1:5.2+dfsg-9
>> Severity: wishlist
>> X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
>>
>> Current packaging of qemu-user-static is providing two different things
>> at once and without any declared configuration possibility (no .conffiles):
>> * QEMU-User statically linked binaries.
>> * binfmt_misc configuration
>
> Yes, it's been this way since forever.
My wording "current packaging" was biased by my wish: that future packaging
doesn't hard-code the configuration within the package :-)
>
>> From release "buster" upwards the binfmt_misc configuration being
>> provided by this package is registering the qemu-user-static binaries
>> with the flag "fix_binary". This configuration might be convenient in
>> most cases (suppose that's was it's so now), but is a problem in some
>> others.
>
>> Not being able to configure binfmt_misc is a blocker for this package in
>> the scenarios where that default configuration doesn't fit. The
>
> So far I don't see where it doesn't fit.
We have the issue that the qemu-user binaries being provided by the host don't
support some syscalls required by some of the running containers.
With the qemu-user-static configuration there's no way around it, since the
"fix_binary" flag doesn't give the container a chance to provide it's own
fitting binaries. Reconfiguring binfmt_misc not to use the "fix_binary" flag
would only survive until next qemu-user-static upgrade.
Therefore the assumption that the qemu-user binaries provided by the host will
fit ALL consumers (containers and chroots included) is wrong for us.
So the only solution is getting rid of the persistence ("fix_binary" flag) of
the host's binaries. But how?
One option is using multiarch/qemu-user-static [1], or doing pretty much the
same ourselves: letting a container change the binfmt_misc configuration of the
host! As you can imagine, that's a security risk and a source for conflicts if
having different containers with different requirements on qemu-user binaries.
I know in fact some people doing so and facing exactly these issues.
[1] https://github.com/multiarch/qemu-user-static
Another possibility is only using qemu-user binaries provided by this package
(pretty much extracting them from the package), but not the configuration and
instead use our own configuration. This solution has less drawbacks than the
previous one, but it's still a hacky workaround to return to the pre-buster
times (where the "fix_binary" flag wasn't active).
>
>
>> configuration can be changed providing different update-binfmts
>> templates than those provided by this package and running
>> update-binfmts. But qemu-user-static upgrades overwrite the changes.
>>
>> I don't know which is the best solution, but one possible is putting
>> the update-binfmts templates now available in /usr/share/binfmts under
>> /etc and making them configuration files (adding a .conffiles).
>
> It seems like way too much trouble for both the maintainer and the user.
IMO current configuration is perfectly fine as a default, but giving the users
the possibility to change it.
I don't really see where do you see the troubles for either maintainer or user.
I wonder why the configuration has to be hard-coded into a package that is
providing very valuable binaries. I'd be happy only with the binaries and being
able to provide my own configuration.
>
>> Just for those curious when this might be an issue. Containers trying to
>> use new syscalls not provided by the QEMU-User binaries provided by the host
>> require newer QEMU-User binaries.
>
> How about installing latest qemu-user-static on host instead? It is a
> self-contained package (as all binaries are statically linked). This way
> all your containers will benefit immediately, too.
Any solution involving the installation of qemu-user-static (no matter if it's
in the host or in a priviledged container) involves using exactly the same
binaries on all consumers. And as mentioned above, doesn't always fit.
>
> Thanks,
>
> /mjt
Thanks for your quick reply,
Silvano
