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

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/3/23 22:13, Jan Kara wrote:
> 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

Yes, my opinion is that FUSE approches are fine, as long as
we clearly document the limitation and the restriction.
For writable filesystems, clearly a full scan fsck is needed
to keep the filesystem consistent in order to avoid potential
data loss at least.

Otherwise, I'm pretty sure some aggressive users will abuse
this feature with "no fsck"...

> 
>>> 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.

Thanks,
Gao Xiang

> 
> 								Honza
>