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

[Christian Brauner <brauner@kernel.org>]

On Tue, Mar 24, 2026 at 08:21:00PM +0800, Gao Xiang wrote:
> 
> 
> 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?

If you want unprivileged filesystem drivers mountable by arbitrary users
and containers then get behind the effort to move this completely out of
the kernel and into fuse making fuse fast enough so that we don't have
to think about it anymore.

The whole push over the last years has been that if users want to mount
arbitrary in-kernel filesystems in userspace then they better built a
delegation and security model _in userspace_ to make this happen. This
is why we built mountfsd in userspace which works just fine today.

I don't understand what exactly people think is going to happen once we
start promising that mounting untrusted images in the kernel for even
one filesystem is fine. This will march us down security madness we have
not experienced before with all of the k8s and container workloads out
there.

For me it is currently still completely irrelevant what filesystem
driver this is and whether it is immutable or not. Look at the size of
your attack surface in your codebase and your algorithms and the ever
expanding functionality it exposes. This pipe dream of "rootless"
containers being able to mount arbitrary images in-kernel without
userspace policy is not workable.

We debate this over and over because userspace is unwilling to accept
that there are fundamental policy problems that are not solved in the
kernel. And that includes when it is safe to mount arbitrary data. This
is especially true now as we're being flooded with (valid and invalid)
CVEs due to everyone believing their personal LLM companion.

You're going to be at LSF/MM/BPF and I'm sure there'll be more
discussion around this.