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

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

On Fri, Feb 06, 2026 at 02:15:12PM +0800, Gao Xiang wrote:
> Hi Darrick,
> 
> On 2026/2/6 13:38, Darrick J. Wong wrote:
> > 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.
> 
> Thanks, but I can't make decisions for every individual end user.
> However, in my view, this approach is valuable for all container
> users if they don't mind to try this approach (I'm building this
> capabilities with several communities and people): they can achieve
> nearly native performance on read-write workloads with a trusted
> fs as well as the remote data source is completely isolated using
> an immutable secure filesystem.
> 
> I will make signed images work first, but as the next step, I'll
> definitely work on defining a clear on-disk boundary (very
> likely excluding per-inode compression layouts in the beginning)
> to enable most users to leverage untrusted data directly in
> a totally isolated user/mount namespace.

<nod> I hope you succeed!

> > 
> > 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.
> 
> Honestly, I've checked what Ted, Dave, and you said previously.
> For generic COW filesystems, it's surely hard to guarantee
> filesystem consistency at all times, mainly because of those
> on-disk formats by design (lots of duplicated metadata for
> different purposes, which can cause extra inconsistency compared
> to archive fses.) Of course, it's not entirely impossible, but
> as Ted pointed out, it becomes a matter of
> 
> 1) human resources;
> 2) enforcing such strict consistency checks harms performance
>    in general use cases which just use trusted filesystem /
>    media directly like databases.
> 
> I'm not against FUSE further improvements because they are seperated
> stories, I do think those items are useful for new Linux innovation,
> but as for the topic of allowing "root" in non-root-user-ns to mount,
> I still insist that it should be a per-filesystem policy, because
> filesystems are designed for different targeted use cases:
> 
>  - either you face and address the issue (by design or by
>    enginneering), or
>  - find another alternative way to serve users.
> 
> But I do hope we shouldn't force some arbitary policy without any
> technical reason, the feature is indeed useful for container users.

Oh yes, the policy question is a very large one; for a specific given
filesystem, you need to trust:

A> whatever user is asking to do the mount

B> the quality of the kernel or userspace drivers

C> the provenance of the filesystem image

This is a hugely personal (or institutional) question, all we can do is
provide mechanisms for kernel and userspace drivers, a sensible default
policy, and a reasonable way to relate all three properties to action.

Or just go with IT policy, which is deny, delete, destroy. :P

> > 
> > > 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.
> 
> I respect this path, but just from my own perspective, userspace
> malicious problems are usually much harder to defence since the
> trusted boundary is weaker, in order to allow unpriviledged
> daemons, you have to monitor if page cache or any metadata cache
> or any potential/undiscovered deadlock vectors can be abused
> by those malicious daemons, so that you have to find more harden
> ways to limit such abused usage naturally since you never trust
> those unpriviledged daemons (which is arbitary executable code
> rather than a binary source) instead, which is opposed to
> performance cases in principle without detailed analysis.

I'm well aware that going to userspace opens a whole floodgate of weird
dynamic behavior possibilities.  Though obviously my experiences with
kernel XFS has shown me that those challenges exist there too. :/

The kernel does have the nice property that you can set NOFS and ignore
SIGSTOP/KILL if necessary to get things done.

--D

> Just my two cents.
> 
> Thanks,
> Gao Xiang
> 
> > 
> > --D
> > 
> > > Thanks,
> > > Gao Xiang
> > > 
> > > 
> 
>