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/24 17:49, Demi Marie Obenour wrote:
> On 3/24/26 05:30, Gao Xiang wrote:
>> Hi Christian,
>>
>> On 2026/3/24 16:48, Christian Brauner wrote:
>>> On Mon, Mar 23, 2026 at 03:47:24PM +0100, 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...
>>>
>>> If this is another 500 mail discussion about FS_USERNS_MOUNT on
>>> block-backed filesystems then my verdict still stands that the only
>>> condition under which I will let the VFS allow this if the underlying
>>> device is signed and dm-verity protected. The kernel will continue to
>>> refuse unprivileged policy in general and specifically based on quality
>>> or implementation of the underlying filesystem driver.
>>
>>
>> First, if block devices are your concern, fine, how about
>> allowing it if EROFS file-backed mounts and S_IMMUTABLE
>> for underlay files is set, and refuse any block device
>> mounts.
>>
>> If the issue is "you don't know how to define the quality
>> or implementation of the underlying filesystem drivers",
>> you could list your detailed concerns (I think at least
>> people have trust to the individual filesystem
>> maintainers' judgements), otherwise there will be endless
>> new sets of new immutable filesystems for this requirement
>> (previously, composefs , puzzlefs, and tarfs are all for
>> this; I admit I didn't get the point of FS_USERNS_MOUNT
>> at that time of 2023; but know I also think FS_USERNS_MOUNT
>> is a strong requirement for DinD for example), because that
>> idea should be sensible according to Darrick and Jan's
>> reply, and I think more people will agree with that.
>>
>> And another idea is that you still could return arbitary
>> metadata with immutable FUSE fses and let users get
>> garbage (meta)data, and FUSE already allows FS_USERNS_MOUNT,
>> and if user and mount namespaces are isolated, why bothering
>> it?
>>
>> I just hope know why? And as you may notice,
>> "Demi Marie Obenour wrote:"
>>
>>> The only exceptions are if the filesystem is incredibly simple
>>> or formal methods are used, and neither is the case for existing
>>> filesystems in the Linux kernel.
>>
>> I still strong disagree with that judgement, a minimal EROFS
>> can build an image with superblock, dirs, and files with
>> xattrs in a 4k-size image; and 4k image should be enough for
>> fuzzing; also the in-core EROFS format even never allocates
>> any extra buffers, which is much simplar than FUSE.
>>
>> In brief, so how to meet your requirement?
>>
>> Thanks,
>> Gao Xiang
> 
> Rewriting the code in Rust would dramatically reduce the attack
> surface when it comes to memory corruption.  That's a lot to ask,
> though, and a lot of work.

I don't think so, FUSE can do FS_USERNS_MOUNT and written in C
, and the attack surface is already huge.

EROFS will switch to Rust some time, but your judgement will
make people to make another complete new toys of Rust kernel
filesystems --- just because EROFS is currently not written
in Rust.

I'm completely exhaused with such game: If I will address
every single fuzzing bug and CVE, why not?

Thanks,
Gao Xiang