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

[Jan Kara <jack@suse.cz>]

On Mon 23-03-26 20:01:32, Gao Xiang wrote:
> On 2026/3/23 19:42, Gao Xiang wrote:
> > > for example, you could audit the file permission with
> > e2fsprogs/xfsprogs without a full fsck scan.
> > 
> > In order to make the userspace programs best-effort, they
> > should open for write and fstat the permission bits
> > before writing sensitive informations, it avoids TOCTOU
> > attacks as much as possible as userspace programs.
> > 
> > 
> > Container users use namespaces of course, namespace can
> > only provide isolations, that is the only security
> > guarantees namespace can provide, no question of that.
> > 
> > Let's just strictly speaking, as you mentioned, both ways
> > ensure the isolation (if namespaces are used) and kernel
> > stability (let's not nitpick about this).  And let's not
> > talk about malicious block devices or likewise, because
> > it's not a typical setup (maybe it could be a typical
> > setup for some cases, but it should be another system-wide
> > security design) and should be clarified by system admins
> > for example.
> > 
> > What I just want to say is that: FUSE mount approach _might_
> > give more incorrect security guarantees than the real users
> > expect: I think other than avoiding system crashes etc, many
> > users should expect that they could use the generic writable
> > filesystem directly with FUSE without full-scan fsck
> > in advance and keep their sensitive data directly, I don't
> 
> 
> If you think that is still the corner cases that users expect
> incorrectly, For example, I think double freeing issues can
> make any useful write stuffs lost just out of inconsistent
> filesystem -- that may be totally unrelated to the security.
> 
> What I want to say is that, the users' interest of new FUSE
> approch is "no full fsck"; Otherwise, if full fsck is used,
> why not they mount in the kernel then (I do think kernel
> filesystems should fix all bugs out of normal consistent
> usage)?
> 
> However, "no fsck" and FUSE mounts bring many incorrect
> assumption that users can never expect: it's still unreliable,
> maybe cannot keep any useful data in that storage.
> 
> Hopefully I explain my idea.

I see and I agree that for some cases FUSE access to the untrusted
filesystem needn't be enough

> > 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.
I would still consider such design highly suspicious but without more
detailed knowledge about the application I cannot say it's outright broken
:).

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR