Bug#1101025: gvfs-fuse: gvfsd-fuse daemon refuses to start

[Simon McVittie]

Control: clone -1 -2
Control: reassign -2 libfuse3-4
Control: retitle -2 libfuse3-4: regression in filesystems that use fuse_conn_info.want
Control: severity -2 important
Control: forwarded -2 https://github.com/libfuse/libfuse/issues/1171

On Sat, 22 Mar 2025 at 13:34:36 +0100, László Böszörményi (GCS) wrote:
>On Sat, Mar 22, 2025 at 1:06 PM Jeremy Bícha <jeremy.bicha at canonical.com> wrote:
>> On Sat, Mar 22, 2025 at 7:51 AM Jens Yllman <jens at yllman.se> wrote:
>> > So, the question is fuse doing this wrong or is gvfs-fuse doing it wrong?
>>
>> I don't know. Someone should report the issue to the gvfs maintainers also.
> Quick check done. It seems in the past FUSE capabilities were a 32
>bit bitfield. It was moved to a 64 bit struct, causing an ABI break.
>It was handled by the SONAME bump and more importantly the FUSE helper
>functions started to use the new bitfield. See the mentioned bitfield
>comments [1][2] in the FUSE header. Both say use the FUSE helper
>functions fuse_set_feature_flag() and fuse_unset_feature_flag()
>instead of accessing internal parts directly.
>But then gvfs (even the one in Trixie / Sid) manipulates the old 32
>bit bitfield directly [3] (and at other places). Meaning it is a gvfs
>bug, a proposed fix is already provided [4].
>In very short, gvfs needs to be fixed. I can't do anything on the FUSE side.

I'm actually not so sure that this is entirely gvfs' fault. From 
discussion on the upstream (gvfs and FUSE) bug reports, it looks like 
FUSE is meant to have backwards-compatibility for the deprecated 32-bit 
bitfield, so that packages like gvfs that still use it will still work; 
but the backwards-compatibility doesn't work, hence the regression.

I've applied the proposed patch you referenced as [4] in gvfs, and I 
think it would be a good thing for gvfs upstream to apply because it 
moves them from a deprecated API to a non-deprecated one; but the same 
issue could equally well affect other FUSE filesystems, so I think 
ideally it would be good to get the backwards compatibility code path 
working again in FUSE *as well* (following the principle that a bad 
interaction between components is often most robustly fixed in both 
components, not just one).

The FUSE issue is <https://github.com/libfuse/libfuse/issues/1171> and a 
proposed fix is <https://github.com/libfuse/libfuse/pull/1172>.

 From https://codesearch.debian.net/search?q=conn-%3Ewant&literal=1 it 
looks like this could affect fuse-overlayfs, xdg-desktop-portal, ntfs-3g 
for example (not verified).

An older gvfs taken from trixie or snapshot.debian.org is probably a 
useful test-case for this.

Thanks,
     smcv