This seems like a band aid, not a proper fix. docker-tar is still run, chrooted into the untrusted container root directory, but in the host's namespace (i.e., ubcontained). As we all know, chroot on Linux is not a security barrier!
I think it would be better to run one docker-tar entirely inside the container, writing to a socket; with another docker-tar on the host reading from the other end of the socket.
Taking a step back though I have to ask why 'docker cp' has to execute anything at all. I would not expect that copying files would need to do anything other than open files within the container and read them. I suppose this would only be possible if the open syscall had a way to prevent symlinks being followed (O_NOFOLLOW is not sufficient because it only applies to the final file in the path, not any parent directories).
Running helper processes entirely in the container is actually quite problematic, since they will be visible to proceses in the container that could try to affect their output. This solution though is used in Kubernetes, and it resulted in 4 vulnerabilities in the last year. Ariel Zelivansky and I just gave a talk on the security of the cp command in KubeCon, you can check out the slides here (https://kccncna19.sched.com/event/d229f00f143036f7c488144e60...) for more information.
As for the fix, I'm pretty sure newer Golang versions stopped dynamiclly loading libraries at runtime, which is nice. I Should have included that in the post but forgot.
Regardless, openat2 looks like a much better solution. I hope it's backported to LTS distros so I can start relying on it before 2035...
For me Docker felt halfway between VirtualBox and Parallels. And VirtualBox had shared folder breakout exploits as far back as 2007.
