Errors when --bind used with a symlinked path

[wenottingham]

When the target of --bind is a symlink, bubblewrap fails.

[root@localhost ~]# mkdir /usr/local/foo
[root@localhost ~]# ln -sf /usr/local/foo /usr/local/cow
[root@localhost ~]# mkdir /tmp/bar
[root@localhost ~]# bwrap --dev-bind / / --bind /tmp/bar /usr/local/cow bash
Can't bind mount /oldroot/tmp/bar on /newroot/usr/local/cow: No such file or directory

[wenottingham]

version: 0.1.7, EL7, setuid.

[wenottingham]

This works if the symlink is relative, presumably because the mount is happening outside of the same namespace.

[alexlarsson]

Yeah, we are resolving the path in the new namespace where / is the in-between root.
Unclear how to solve this in a robust way, other than possibly resolving the directories before going all namespace:y (although care must be taken to resolve it without setuid root perms).

[wenottingham]

We've adjusted how we call bubblewrap to realpath() all paths we pass to it beforehand, in case this is deemed intractable to fix.

[jackhill]

I believe that I've run into this while troubleshooting a WebKitGTK bug on GNU Guix. In this case the application is generating an --ro-bind /etc /etc followed by an --ro-bind-try /etc/pulse/client.conf /etc/pulse/client.conf. Both /etc/pulse and /etc/pulse/client.conf are absolute symlinks.

That said, I'm not sure what the right solution is. Should this be solved in the calling application or in Bubblewrap? If the former, what fix do you recommend?

[smcv]

I think the solution is probably for the calling application to canonicalize the paths. Unlike bubblewrap, the calling application is (presumably) not setuid and does not need to be careful to avoid accidentally revealing information that should not have been available to the caller.

[alexlarsson]

Flatpak also canonicalizes all paths it passes to bwrap

[mcatanzaro]

Certainly seems like the path of least-resistance. But if so, then we should close this issue, because open issue indicates intent to fix in bubblewrap IMO. ;)

[jackhill]

Thanks, canonicalizing paths before passwing them to Bubblewrap sounds like a good path forward.

In general, I agree that it seems like this issue can be closed if there is not a fix to be made in Bubblewrap. However, I wonder if improvements could be made. For example, the documentation could be updated indicating that paths should be canonicalized or the error reporting could be improved to warn against the use of symbolic links. The latter would definitely help those troubleshooting this type of problem.