Control: tag -1 pending
14.02.2021 00:56, Thorsten Glaser wrote:
Michael Tokarev dixit:
13.02.2021 13:19, Michael Tokarev wrote:
The problem with the wrapper is that it effectively nullifies
the F flag of binfmt. That is, with F and the binfmt interpreter
being the qemu binary directly, we can use regular, non-static,
qemu-user, or qemu-user-static, and run the thing from outside
of the foreign chroot.
But with the wrapper, we have to have the actual qemu-user binary
runnable within the foreign chroot *too*, - only the wrapper will
Oh? I’m always copying the qemu-user-static binaries into the
chroot and you’re really telling me I didn’t need to? õÕ
This is not needed since v.2.12. So this is buster, but not stretch.
This is fix-binary binfmt-misc flag and #868030 . Many users got
used to that already in buster and buster-backports :)
I can think of another hack. Qemu-user binary may look at its
name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
it will assume it is run from within the binfmt subsystem with
the P flag in effect. Yes it is hacky, but it *might* work.
Actually this is something I like. Yes it is hackish but it works.
So I implemented this, using /usr/libexec/qemu-binfmt/foo-binfmt-P
symlinks to ../../bin/qemu-foo[-static], and detecting "-binfmt-P"
prefix in qemu-user/main.c.
Ah, with the P flag the argv[0] of the interpreter is not changed,
so this can work. Yes, this sounds like a really good idea.
Thank you! And it works well too. I plan to walk over the pile of
security issues tomorrow and hopefully upload a new version too.
Thanks,
/mjt
