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

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

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