DoS against new CVMFS mounts from userspace

Mounting a CVMFS repository on the host, and then running, as normal user:

unshare --user --mount --map-root-user

cd /cvmfs/singularity.opensciencegrid.org

it is possible to unmount the cvmfs-repo (e.g. via autofs timeout, or via umount)
since no FD is held in the host mount namespace.
This is common for all FUSE fs: The umount is successful, the mount vanishes on the host, the cvmfs2 helper keeps running to serve the FD held open in the user mount namespace. Inside the user mount namespace, cvmfs continues to work as expected.

However, contrary to other FUSE fs, in case of CVMFS, future mounts are denied in that situation:

$ ls /cvmfs/singularity.opensciencegrid.org

ls: cannot open directory '/cvmfs/singularity.opensciencegrid.org': No such fi or directory

Trying to mount manually, I see:

$ mount -t cvmfs singularity.opensciencegrid.org  /tmp/foo

Repository singularity.opensciencegrid.org is already mounted on /tmp/foo

(for the wrong error message, c.f. CVM-1477 ).

So effectively, any user without malicious intent can DoS any CVMFS mount on any machine with user namespace support enabled.

More realistically than manual unshare, users might use runc or charliecloud which can be run unprivilegedly at any site.

A proposed solution could be to look at other FUSE implementations (such as ntfs-3g) and implement it like they do, i.e. the already running unique helper per repository takes care of the new mount request in the host mount namespace.

Another solution would be to implement it like sshfs (one helper per mount request), but this does not match the design of CVMFS.

Cheers,
Oliver