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

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

On 2026/3/23 22:47, Jan Kara wrote:
> On Mon 23-03-26 22:36:46, Gao Xiang wrote:
>> On 2026/3/23 22:13, Jan Kara wrote:
>>>>> think that is the corner cases if you don't claim the
>>>>> limitation of FUSE approaches.
>>>>>
>>>>> If none expects that, that is absolute be fine, as I said,
>>>>> it provides strong isolation and stability, but I really
>>>>> suspect this approach could be abused to mount totally
>>>>> untrusted remote filesystems (Actually as I said, some
>>>>> business of ours already did: fetching EXT4 filesystems
>>>>> with unknown status and mount without fscking, that is
>>>>> really disappointing.)
>>>
>>> Yes, someone downloading untrusted ext4 image, mounting in read-write and
>>> using it for sensitive application, that falls to "insane" category for me
>>> :) We agree on that. And I agree that depending on the application using
>>> FUSE to access such filesystem needn't be safe enough and immutable fs +
>>> overlayfs writeable layer may provide better guarantees about fs behavior.
>>
>> That is my overall goal, I just want to make it clear
>> the difference out of write isolation, but of course,
>> "secure" or not is relative, and according to the
>> system design.
>>
>> If isolation and system stability are enough for
>> a system and can be called "secure", yes, they are
>> both the same in such aspects.
>>
>>> I would still consider such design highly suspicious but without more
>>> detailed knowledge about the application I cannot say it's outright broken
>>> :).
>>
>> What do you mean "such design"?  "Writable untrusted
>> remote EXT4 images mounting on the host"? Really, we have
>> such applications for containers for many years but I don't
>> want to name it here, but I'm totally exhaused by such
>> usage (since I explained many many times, and they even
>> never bother with LWN.net) and the internal team.
> 
> By "such design" I meant generally the concept that you fetch filesystem
> images (regardless whether ext4 or some other type) from untrusted source.
> Unless you do cryptographical verification of the data, you never know what
> kind of garbage your application is processing which is always invitation
> for nasty exploits and bugs...

That is very common for Docker images for example
(Although I admit Docker images now use TAR archives,
which can be seen as an immutable system too).

For example, Docker Hub keeps TAR images with sha256, but
only sha256 without any cryptographical signature.  Of
course, you could rely on your image scanner to audit
malicious contents if you want (e.g. you keep your sensitive
information) or rely on 3rd-party applications to scan for
you, or never scan since you don't keep any sensitive
information in that.  --- so because Docker image will
write into another trusted local filesystem like the
model I mentioned before.

IOWs, the image sha256 only ensures that "the tar images
you downloaded" is what "the publisher once uploaded",
no more than that.  And that model is also our interest,
since the core EROFS format should fit such model too.

Thanks,
Gao XIang

> 
> 								Honza