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 19:58, Demi Marie Obenour wrote:
> On 3/24/26 04:48, Christian Brauner wrote:

...

>>>>
>>>>> 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.
> 
> As far as I can tell, the main problems are:
> 
> 1. Most filesystems can only be run in kernel mode, so one needs a
>     VM and an expensive RPC protocol if one wants to run them in a
>     sandboxed environment.
> 
> 2. Context switch overhead is so high that running filesystems entirely
>     in userspace, without some form of in-kernel I/O acceleration,
>     is a performance problem.
> 
> 3. Filesystems are written in C and not designed to be secure against
>     malicious on-disk images.
> 
> Gao Xiang is working on problem for EROFS.
> FUSE iomap support solves 2.  lklfuse solves problem 1.

Sigh, I just would like to say, as Darrick and Jan's previous
replies, immutable on-disk fses are a special kind of filesystems
and the overall on-disk format is to provide vfs/MM basic
informattion (like LOOKUP, GETATTR, and READDIR, READ), and the
reason is that even some values of metadata could be considered
as inconsistent, it's just like FUSE unprivileged daemon returns
garbage (meta)data and/or TAR extracts garbage (meta)data --
shouldn't matter at all.

Why I'm here is I'm totally exhaused by arbitary claim like
"all kernel filesystem are insecure". Again, that is absolutely
untrue: the feature set, the working model and the implementation
complexity of immutable filesystems make it more secure by
design.

Also the reason of "another 500 mail discussion about
FS_USERNS_MOUNT" is just because "FS_USERNS_MOUNT is very very
useful to containers", and the special kind of immutable on-disk
filesystems can fit this goal technically which is much much
unlike to generic writable ondisk fses or NFS and why I working
on EROFS is also because I believe immutable ondisk filesystems
are absolutely useful, more secure than other generic writable
fses by design especially on containers and handling untrusted
remote data.

I here claim again that all implementation vulnerability of
EROFS will claim as 0-day bug, and I've already did in this way
for many years.  Let's step back, even not me, if there are
some other sane immutable filesystems aiming for containers,
they will definitely claim the same, why not?

Thanks,
Gao Xiang