I clarified a bit my understsanding of how glusterfs is using fuse. Long comment below.

TL;DR
gluster uses its own copy of fuse for both the fuse xlator, and the fusermount tool (called fusermount-glusterfs). It won't use fuse's fusermount. This also means the depdendencies on libfuse-dev (build) and fuse (runtime) could be dropped.


There are two aspects to this: fusermount-glusterfs, and the fuse xlator mount module.

/usr/bin/fusermount-glusterfs is used when an unprivileged user tries a mount:

  I [mount.c:496:gf_fuse_mount] 0-glusterfs-fuse: direct mount failed (Operation not permitted) errno 1
  I [mount.c:501:gf_fuse_mount] 0-glusterfs-fuse: retry to mount via fusermount

For this to work, two conditions need to be met:
a) the gluster provided /usr/bin/fusermount-glusterfs binary must be built and used (the fuse provided one is ignored)
b) it must be installed SUID root, just like fuse's /usr/bin/fusermount

If a privileged user is doing the mount, then gluster uses a direct mount and fusermount-glusterfs is not used.

Can we then perhaps disable gluster's fusermount, and use the one provided by fuse (/usr/bin/fusermount), which is installed suid root already? No. gluster will not even attempt to use the fuse fusermount command. This then goes down to technical differences between fuse's and gluster's fusermount, some of which are explained in https://github.com/gluster/glusterfs/discussions/2212

The Debian and Ubuntu packaging, as is, do not allow unprivileged mounts, because they ship /usr/bin/fusermount-glusterfs without the SUID root bit set. It might have been a conscious decision, letting the sysadmin decide if they want to enable that bit or not, and keep it during upgrades. Or it's a bug. In any case, they way it is shipped, we could be using --disable-fusermount and would see no difference in behavior.

But gluster still uses fuse.

On to the second point.

Both the fusermount-glusterfs binary, and the fuse xlator, use embedded copies of fuse, in the contrib/ directory. They are not full copies, just enough to build what is needed.

This also means that there is no need for the libfuse-dev build-dependency on the package, and there is also no need for the `fuse` Depends. I built the glusterfs packages with this patch applied, and no fuse packages installed on the system whatsoever:
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,6 @@ Section: admin
 Priority: optional
 Maintainer: Patrick Matthäi <email address hidden>
 Build-Depends: debhelper-compat (= 13),
- libfuse-dev <!nocheck>,
  libibverbs-dev <!nocheck>,
  libdb-dev <!nocheck>,
  librdmacm-dev <!nocheck>,
@@ -37,7 +36,6 @@ Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  ${python3:Depends},
- fuse,
  glusterfs-common (>= ${binary:Version})
 Description: clustered file-system (client package)
  GlusterFS is a clustered file-system capable of scaling to several

It built just fine:
$ dpkg --contents ../glusterfs-client_10.0-2ubuntu1~ppa1_amd64.deb |grep fuse
-rwxr-xr-x root/root     35048 2022-01-13 20:42 ./usr/bin/fusermount-glusterfs
lrwxrwxrwx root/root         0 2022-01-13 20:42 ./usr/share/man/man8/fusermount-glusterfs.8.gz -> mount.glusterfs.8.gz

$ dpkg --contents ../glusterfs-common_10.0-2ubuntu1~ppa1_amd64.deb |grep fuse
-rw-r--r-- root/root    243168 2022-01-13 20:42 ./usr/lib/x86_64-linux-gnu/glusterfs/10.0/xlator/mount/fuse.so

$ dpkg -l | grep fuse
$

I will next file an upstream bug to switch to the externally provided fuse libraries. It may not be possible for the fusermount-glusterfs case, but that can at least be a build-time decision and is gated on whether we want to allow unprivileged mounts or not.

Furthermore, I'll file one or two debian bugs to at least have the discussion started on these respective issues:
a) remove fuse build-depends and Depends, since they are not needed
b) either disable fusermount-glusterfs, or install it suid root, or leave it as is, but document that for it to work the admin needs to chmod u+s that binary and use dpkg-statoverride to not lose that during upgrades.