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

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

Hi Demi,

On 2026/3/22 11:25, Demi Marie Obenour wrote:

...

> 
>>> "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).
>>
>> (Yeah, that's probably the only way to go for prepopulated images like
>> root filesystems and container packages)
> 
> Even an immutable filesystem can still be corrupt.

I disagree with you here, I think we need define what kind of
corruption is really harmful to systems.

I can definitely say, if an immutable filesystem is well-defined,
it cannot bring any harmful behaviors to the systems.

Taking one example, nlink can still be mismatched for immutable
filesystems, but does it have any real impact?

  1) you can write an unpriviledged FUSE daemon to return arbitary
     nlink all the time, so getattr results doesn't really matter;

  2) OverlayFS and some other fses I don't remember now will return
     nlink = 1 all the time.

As long as the mount/user namespace are totally isolated (of course
you shouldn't mix with the other namespaces), I cannot think out
a real practical attack patch to attack users __just out of the
well-designed immutable filesystems__.

According to the EROFS on-disk format for example, some field of
course can still be considered as corruption, but so what?  It
cannot bring any harmful behavior like the other generic writable
filesystems, which much rely on the allocation metadata, nlink,
etc. are absolutely correct, otherwise the write paths are hightly
vulnerable.

Let's keep in other words, many situations, you still need to
download archive files (like zip, tar, etc.) from the internet,
but without any verification hash for example: Sometimes we face
random corruptions out of these archive files, but so what?
such archives can be extracted with garbage data, or garbage
metadata, but if the namespaces are isolated, what's the real
impact to the computer systems or users?

That is all I want to say, if you find any real impact, let just
write down the real attack paths, but that is all my ideas in
mind.

Thanks,
Gao Xiang