Hi Laurent, > Are there some reasons to not use binfmt_misc when we are able to do > chroot ? > > Moreover binfmt_misc allows to execute binaries that cannot be read, I > think it is not possible with an userspace solution. And binfmt_misc > also allows to use credential and security tokens from the binaries, not > from the interpreter (See [1]), it is useful to run commands like "sudo". > > With this solution, you can't mix several interpreters in your chroot: I > guess LXC has templates to create (ubuntu) containers where some > binaries are statically linked native ones to manage syscalls (like > netlink) that are not supported by qemu linux-user. > > I think it is better to use kernel mechanisms when they are available...
Definitely! If binfmt_misc is available as an option then it is a superior choice for all the reasons and edge cases you outlined above. However, binfmt_misc isn't always a choice. Even if you have enough permissions to do a chroot() the module might just not be available or you might not have enough permissions to load it and configure it. Maybe it would make sense to add some caveats of this option in the documentation? > That said, I have nothing against the idea but I don't understand what > it is useful for... do you have some use cases ? My main use case for this is opening up the possibility to build ARM Docker images using hosted services like Dockerhub where you don't have access to the kernel. Also, it allows projects on Github to use services like Travis CI to do continuous integration and testing on foreign architectures. I assume it will also work under a fakechroot although I haven't tested this. I've written a blog post[1] on the details of the usecase and it has been found to be very useful from people in the Docker for ARM community. [1] https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/ Best, Petros
