Handle mount_point being within a branch

[normanr]

If the mount_point is within a branch, then you can end up with recursive reads. Even worse if you use the mount point as the branch unionfs gets caught in a deadlock because fuse very quickly exhausts its threads.

The easiest may be to just check if the mount point is within the branch and deny access to it. This may not handle symlinks, but might be good enough.

An alternative would be to preventing access of unionfs itself by using fuse_get_context to get the pid associated with the request and denying access if the pid matches. There may be some additional complexity because of multi-threading (pid is the thread id, not process id). This could be worked around by keeping a list of tid's of threads that are running ops, and denying requests if they originate from one of those threads. I think this would fix the symlink issue.

Another way could be to unshare mount namespaces, and mount a ro tmpfs at the mountpoint, so that unionfs can't read from its own mount (or some magic so that it can read from underneath it's mount!?!). This does require kernel support for mount namespaces though. You'd have to unshare mount namespaces before fuse_mount, (so that the mount doesn't affect the child process), and fuse_main currently calls fuse_daemonize after fuse_mount.

fuse does support passing the /dev/fuse fd via mount point options (but only since fuse 3.3.0), so this might be do-able with a script above unionfs if unionfs could be updated to use fuse 3.3 or higher.

[rpodgorny]

If the mount_point is within a branch

...what would be the use-case for doing this?

[normanr]

I came across it when using unionfs as a way to store build artifacts outside of the source tree in non-cmake projects (for cmake you can just do cmake -Bbuild -S.), eg:

git checkout [url]
cd project
mkdir .build-data
mkdir build
unionfs .build-data=rw:.=ro build
cd build
./configure.sh
make

It's easy enough to arrange things so that the mount is outside of the branch, but it would be convenient to be able to put it within. (Being able to read the data under the mount is just a storage optimization, but far more complex to implement, so I don't think worth worrying about for now.)