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? õÕ
>> 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.
Thanks,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
