Skip to content

/proc/self/exe not handled in execve

Description of problem

I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this.

My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with execve /proc/self/exe. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use...

Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary emulated, as opposed to qemu-system which runs an entire system but is harder to automate in toolchains) we need these patches because of a peculiar thing many golang applications do. They re-execute themselves using the execve syscall using /proc/self/exe as the executable. In non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the top-level emulator process and not podman/buildah/skopeo. This causes all container storage operations to mysteriously fail, because the wrong binary is being executed. This issue was quite difficult to root cause.

Additional information

Old patchsets that seem to be trying to fix this:

It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information