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

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 05, 2026 at 06:50:28AM +0800, Gao Xiang wrote:
> 
> 
> On 2026/2/5 03:06, Darrick J. Wong wrote:
> > On Mon, Feb 02, 2026 at 02:51:04PM +0100, Miklos Szeredi wrote:
> 
> ...
> 
> > 
> >   4 For defaults situations, where do we make policy about when to use
> >     f-s-c and when do we allow use of the kernel driver?  I would guess
> >     that anything in /etc/fstab could use the kernel driver, and
> >     everything else should use a fuse container if possible.  For
> >     unprivileged non-root-ns mounts I think we'd only allow the
> >     container?
> 
> Just a side note: As a filesystem for containers, I have to say here
> again one of the goal of EROFS is to allow unprivileged non-root-ns
> mounts for container users because again I've seen no on-disk layout
> security risk especially for the uncompressed layout format and
> container users have already request this, but as Christoph said,
> I will finish security model first before I post some code for pure
> untrusted images.  But first allow dm-verity/fs-verity signed images
> as the first step.

<nod> I haven't forgotten.  For readonly root fses erofs is probably the
best we're going to get, and it's less clunky than fuse.  There's less
of a firewall due to !microkernel but I'd wager that most immutable
distros will find erofs a good enough balance between performance and
isolation.

Fuse, otoh, is for all the other weird users -- you found an old
cupboard full of wide scsi disks; or management decided that letting
container customers bring their own prepopulated data partitions(!) is a
good idea; or the default when someone plugs in a device that the system
knows nothing about.

> On the other side, my objective thought of that is FUSE is becoming
> complex either from its protocol and implementations (even from the

It already is.

> TODO lists here) and leak of security design too, it's hard to say
> from the attack surface which is better and Linux kernel is never
> regarded as a microkernel model. In order to phase out "legacy and
> problematic flags", FUSE have to wait until all current users don't
> use them anymore.
> 
> I really think it should be a per-filesystem policy rather than the
> current arbitary policy just out of fragment words, but I will
> prepare more materials and bring this for more formal discussion
> until the whole goal is finished.

Well yes, the transition from kernel to kernel-or-fuse would be
decided on a per-filesystem basis.  When the fuse driver reaches par
with the kernel driver on functionality and stability then it becomes a
candidate for secure container usage.  Not before.

--D

> Thanks,
> Gao Xiang
> 
>