Symlink resolution fails for non-existent subfolders

[sandro-h]

Our use case is whitelisting which host paths can be mounted into Docker containers. To avoid symlink workarounds, we use the Resolved field, as recommended in the README, but fall back to Source if Resolved is empty. This works fine, except when mounting a path that contains a symlink and a non-existent subfolder:

# Is blocked by opa-docker-authz because our policy file prevents mounting anything under /etc:
docker run --rm -it -v /etc:/work busybox

# Trying to work around it with a symlink. Is also blocked as expected:
ln -s /etc etc
docker run --rm -it -v $(pwd)/etc:/work busybox

# Is NOT blocked, letting me create a folder and other content under /etc/nonexistent:
docker run --rm -it -v $(pwd)/etc/nonexistent:/work busybox

While this perhaps has limited security implications, since I can only create a new folder and not read any existing content in /etc, it could still be problematic in some edge cases.

The underlying issue is that filepath.EvalSymlinks fails when it tries to run os.Lstat on /etc/nonexistent because it doesn't exist. By comparison, Python's pathlib.Path will simply return the resolved path /etc/nonexistent as expected.

A possible solution/workaround is to catch the PathError and return whatever it resolved (ugly code):

resolved, err := filepath.EvalSymlinks(bindMount.Source)
if err == nil {
	resolved = filepath.Clean(resolved)
	result[idx].Resolved = resolved
} else if pathErr, ok := err.(*os.PathError); ok && pathErr.Err == syscall.ENOENT {
	resolved = filepath.Clean(pathErr.Path)
	result[idx].Resolved = resolved
}

However, to me this relies a bit too much on the internals of EvalSymlinks.

[anderseknert]

Thanks for raising this issue @sandro-h. As I recall, not the first time we're seeing issues with symlinks in this repo 😅 I'm afraid I don't have the bandwidth to explore this in depth right now, but if you come up with a solution you're pleased with, I'm happy to review that.

[sandro-h]

Thanks for the reply, @anderseknert! I've applied my proposed solution to a fork for the time being, which works well enough for our use case. But I'm not confident this is a good general purpose solution, so I'll invest a bit more time to try and come up with something better. I'll open a PR once it looks reasonable.

[sandro-h]

Some notes from my experimentation for later: the workaround proposed in the issue description has other problems. Since it fails fast, before resolving the full path, you can do things like this:

# Resolves to /etc (assuming pwd is 3 levels deep)
docker run --rm -it -v $(pwd)/nonexistent/../../../etc:/work busybox

The workaround solution would return $(pwd)/nonexistent. In our fork we now delegate this to readlink -m which seems to handle all these edge cases correctly. Of course that is not a nice nor portable solution, but works for our deployment scenario.

It looks more and more like this needs a custom implementation to resolve paths in a more robust way. Which doesn't sound very fun nor really in scope of the plugin, especially for Windows. One idea is to port (if conforming to licenses) the Python standard library solution, and maybe skip the Windows complexity by delegating to EvalSymlinks (with appropriate documentation).