The bug reported here is because Docker sanitizes the symlinks within a path to ensure that nothing is trying link to something outside a given path, then it o

The bug reported here is because Docker sanitizes the symlinks within a path to ensure that nothing is trying link to something outside a given path, then it operates on the filesystem. This filesystem is shared with the containerized process. So after Docker sanitizes the path, a malicious container process can do bad things to the path and Docker will assume that everything is still ok, the process will then gain read/write access to host files. I think a non-privileged user (or the use of user namespaces) would limit the scope of the attack based on permissions (though you have to make sure there is no suid binaries on the host as well... or use no-new-privileges for the container), however the attack still exists.