FUSE workers incompatible with meta-fuse-csi-plugin due to go-fuse stripping environment variables

[anguslees]

Problem

Buildbarn's FUSE-based workers (e.g. bb_virtual_tmp) cannot be used with meta-fuse-csi-plugin for Kubernetes-based deployments. The meta-fuse-csi-plugin project provides a fusermount3-proxy that allows unprivileged containers to mount FUSE filesystems via a CSI driver, which is particularly useful for running bb-remote-execution workers in Kubernetes without privileged containers or SYS_ADMIN capabilities.

The root cause is in the upstream go-fuse library: the callFusermount() function strips all environment variables when invoking the fusermount3 binary, passing only _FUSE_COMMFD=3. This means fusermount3-proxy never receives its required FUSERMOUNT3PROXY_FDPASSING_SOCKPATH environment variable and cannot locate the CSI driver's fd-passing socket.

Upstream Fix

I've submitted a fix upstream: hanwen/go-fuse#600

The fix passes through the parent process's full environment to the fusermount subprocess while still explicitly setting _FUSE_COMMFD=3. go-fuse is not a security boundary, and I suspect this environment stripping was always just an unintentional oversight.

Suggested Action

Since bb-remote-execution already applies patches to its go-fuse dependency, it may be worth applying this patch in the interim until/unless the upstream PR is merged. This would enable Buildbarn FUSE workers to be deployed in Kubernetes via meta-fuse-csi-plugin without requiring privileged containers.

The change is small — it adds a filterEnv() helper and modifies one line in callFusermount() to pass through os.Environ() instead of a hardcoded minimal environment.