binfmt_misc registration leaks into Docker containers

[EchterAgo]

AppImageLauncher's binfmt_misc registration leaks into Docker containers which causes AppImages to fail to launch inside the container.

There's a bunch of workarounds. You could just deploy AppImageLauncher's binfmt wrapper tool into all Docker containers, and call the AppImages via that.

See AppImageCommunity/pkg2appimage#373

[TheAssassin]

I haven't managed to find a good workaround yet. The two known ones are:

• patch AppImage so it doesn't trigger the binfmt_misc integration any more
• use binfmt_bypass binary (I think you could try copying it to /usr/bin/AppImageLauncher even)

Docker uses binfmt_misc to, e.g., support running foreign architectures using QEMU (must be installed in the container as well, at the right paths).

In our case, we would like to ignore the AppImageLauncher integration, but I'm not aware of any such options. Also, disabling it entirely would mean one could not use QEMU in containers any more.

[Korkman]

What about this option for update-binfmts?

--fix-binary yes, --fix-binary no
Whether to open the interpreter binary immediately and always use the opened image. This allows the interpreter from the host to be used regardless of usage in chroots or different mount namespaces. The default behaviour is no, meaning that the kernel should open the interpreter binary lazily when needed. This option requires Linux 4.8 or newer. It cannot be used together with --detector, or with multiple binary formats that share the same magic number, since the kernel will only open a single interpreter binary which will then not be able to detect and execute the real interpreter from inside a chroot or from a different mount namespace.

AppImage Launcher would then have to test if it is being run in a valid context first and if not somehow exec() the binary with the correct handler.

[TheAssassin]

@Korkman that's an excellent hint, thank you very much! I wonder why I've never seen that flag before. I'm going to add a minimal binary to /usr/lib/<triplet>/appimagelauncher as an interpreter. This binary can then check whether /usr/bin/AppImageLauncher exists (with the option to add further checks in the future), and if it is there, execute AppImageLauncher on the binary, otherwise perform the binfmt-bypass workaround (I can probably integrate it directly in that binary).