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

[Christian Brauner <brauner@kernel.org>]

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.