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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 4926 bytes --]

On 3/24/26 05:30, Gao Xiang wrote:
> Hi Christian,
> 
> On 2026/3/24 16:48, Christian Brauner wrote:
>> 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.
> 
> 
> First, if block devices are your concern, fine, how about
> allowing it if EROFS file-backed mounts and S_IMMUTABLE
> for underlay files is set, and refuse any block device
> mounts.
> 
> If the issue is "you don't know how to define the quality
> or implementation of the underlying filesystem drivers",
> you could list your detailed concerns (I think at least
> people have trust to the individual filesystem
> maintainers' judgements), otherwise there will be endless
> new sets of new immutable filesystems for this requirement
> (previously, composefs , puzzlefs, and tarfs are all for
> this; I admit I didn't get the point of FS_USERNS_MOUNT
> at that time of 2023; but know I also think FS_USERNS_MOUNT
> is a strong requirement for DinD for example), because that
> idea should be sensible according to Darrick and Jan's
> reply, and I think more people will agree with that.
> 
> And another idea is that you still could return arbitary
> metadata with immutable FUSE fses and let users get
> garbage (meta)data, and FUSE already allows FS_USERNS_MOUNT,
> and if user and mount namespaces are isolated, why bothering
> it?
> 
> I just hope know why? And as you may notice,
> "Demi Marie Obenour wrote:"
> 
>> The only exceptions are if the filesystem is incredibly simple
>> or formal methods are used, and neither is the case for existing
>> filesystems in the Linux kernel. 
> 
> I still strong disagree with that judgement, a minimal EROFS
> can build an image with superblock, dirs, and files with
> xattrs in a 4k-size image; and 4k image should be enough for
> fuzzing; also the in-core EROFS format even never allocates
> any extra buffers, which is much simplar than FUSE.
> 
> In brief, so how to meet your requirement?
> 
> Thanks,
> Gao Xiang

Rewriting the code in Rust would dramatically reduce the attack
surface when it comes to memory corruption.  That's a lot to ask,
though, and a lot of work.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]