Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

[Gao Xiang <hsiangkao@linux.alibaba.com>]

Hi Darrick,

On 2026/2/21 08:47, Darrick J. Wong wrote:
> On Fri, Feb 06, 2026 at 02:15:12PM +0800, Gao Xiang wrote:

...

> 
>>>
>>> Fuse, otoh, is for all the other weird users -- you found an old
>>> cupboard full of wide scsi disks; or management decided that letting
>>> container customers bring their own prepopulated data partitions(!) is a
>>> good idea; or the default when someone plugs in a device that the system
>>> knows nothing about.

I brainstormed some more thoughts:

End users would like to mount a filesystem, but it's unknown that
the filesystem is consistent or not, especially for filesystems
are intended to be mounted as "rw", it's very hard to know if the
filesystem metadata is fully consistent without a full fsck scan
in advance.

Considering the following metadata inconsistent case (note that
block 0x123 is referenced by the inconsistent metadata, rather
than normal filesystem reflink with correct metadata):

  inode A (with high permission)
  extent [0~4k)               maps to block 0x123

  random inode B (with low permission)
  extent [0~4k)               maps to block 0x123 too

So there will exist at least three attack ways:

  1) Normal users will record the sensitive information to inode
     A (since it's not the normal COW, the block 0x123 will be
     updated in place), but normal users don't know there exists
     the malicious inode B, so the sensitive information can be
     fetched via inode B illegally;

  2) Attackers can write inode B with low permission in the proper
     timing to change the inode A to compromise the computer
     system;

  3) Of course, such two inodes can cause double freeing issues.

I think the normal copy-on-write (including OverlayFS) mechanism
doesn't have the issue (because all changes will just have another
copy). Of course, hardlinking won't have the same issue either,
because there is only one inode for all hardlinks.

I don't think FUSE-implemented userspace drivers will resolve
such issues (I think users can only get the following usage reclaim:
"that is not the case that we will handle with userspace FUSE
drivers, because the metadata is serious broken"), the only way to
resolve such attack vectors is to run

the full-scan fsck consistency check and then mount "rw"

or

using the immutable filesystem like EROFS (so that there will not
be such inconsisteny issues by design) and isolate the entire write
traffic with a full copy-on-write mechanism with OverlayFS for
example (IOWs, to make all write copy-on-write into another trusted
local filesystem).

I hope it's a valid case, and that can indeed happen if the arbitary
generic filesystem can be mounted in "rw".  And my immutable image
filesystem idea can help mitigate this too (just because the immutable
image won't be changed in any way, and all writes are always copy-up)

Thanks,
Gao Xiang