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: 3426 bytes --]

On 3/24/26 04: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.

As far as I can tell, the main problems are:

1. Most filesystems can only be run in kernel mode, so one needs a
   VM and an expensive RPC protocol if one wants to run them in a
   sandboxed environment.

2. Context switch overhead is so high that running filesystems entirely
   in userspace, without some form of in-kernel I/O acceleration,
   is a performance problem.

3. Filesystems are written in C and not designed to be secure against
   malicious on-disk images.

Gao Xiang is working on problem for EROFS.
FUSE iomap support solves 2.  lklfuse solves problem 1.
-- 
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 --]