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

On 3/23/26 08:13, Gao Xiang wrote:
> 
> 
> On 2026/3/23 20:08, Demi Marie Obenour wrote:
>> On 3/23/26 07:14, Jan Kara wrote:
>>> Hi Gao!
>>>
>>> On Mon 23-03-26 18:19:16, Gao Xiang wrote:
>>>> On 2026/3/23 17:54, Jan Kara wrote:
>>>>> On Sun 22-03-26 12:51:57, Gao Xiang wrote:
>>>>>> On 2026/3/22 11:25, Demi Marie Obenour wrote:
>>>>>>>> Technically speaking fuse4fs could just invoke e2fsck -fn before it
>>>>>>>> starts up the rest of the libfuse initialization but who knows if that's
>>>>>>>> an acceptable risk.  Also unclear if you actually want -fy for that.
>>>>>>>
>>>>>>
>>>>>> Let me try to reply the remaining part:
>>>>>>
>>>>>>> To me, the attacks mentioned above are all either user error,
>>>>>>> or vulnerabilities in software accessing the filesystem.  If one
>>>>>>
>>>>>> There are many consequences if users try to use potential inconsistent
>>>>>> writable filesystems directly (without full fsck), what I can think
>>>>>> out including but not limited to:
>>>>>>
>>>>>>    - data loss (considering data block double free issue);
>>>>>>    - data theft (for example, users keep sensitive information in the
>>>>>>         workload in a high permission inode but it can be read with
>>>>>>         low permission malicious inode later);
>>>>>>    - data tamper (the same principle).
>>>>>>
>>>>>> All vulnerabilities above happen after users try to write the
>>>>>> inconsistent filesystem, which is hard to prevent by on-disk
>>>>>> design.
>>>>>>
>>>>>> But if users write with copy-on-write to another local consistent
>>>>>> filesystem, all the vulnerabilities above won't exist.
>>>>>
>>>>> OK, so if I understand correctly you are advocating that untrusted initial data
>>>>> should be provided on immutable filesystem and any needed modification
>>>>> would be handled by overlayfs (or some similar layer) and stored on
>>>>> (initially empty) writeable filesystem.
>>>>>
>>>>> That's a sensible design for usecase like containers but what started this
>>>>> thread about FUSE drivers for filesystems were usecases like access to
>>>>> filesystems on drives attached at USB port of your laptop. There it isn't
>>>>> really practical to use your design. You need a standard writeable
>>>>> filesystem for that but at the same time you cannot quite trust the content
>>>>> of everything that gets attached to your USB port...
>>>>
>>>> Yes, that is my proposal and my overall interest now.  I know
>>>> your interest but I'm here I just would like to say:
>>>>
>>>> Without full scan fsck, even with FUSE, the system is still
>>>> vulnerable if the FUSE approch is used.
>>>>
>>>> I could give a detailed example, for example:
>>>>
>>>> There are passwd files `/etc/passwd` and `/etc/shadow` with
>>>> proper permissions (for example, you could audit the file
>>>> permission with e2fsprogs/xfsprogs without a full fsck scan) in
>>>> the inconsistent remote filesystems, but there are some other
>>>> malicious files called "foo" and "bar" somewhere with low
>>>> permissions but sharing the same blocks which is disallowed
>>>> by filesystem on-disk formats illegally (because they violate
>>>> copy-on-write semantics by design), also see my previous
>>>> reply:
>>>> https://lore.kernel.org/r/7de8630d-b6f5-406e-809a-bc2a2d945afb@linux.alibaba.com
>>>>
>>>> The initial data of `/etc/passwd` and `/etc/shadow` in the
>>>> filesystem image doesn't matter, but users could then keep
>>>> very sensitive information later just out of the
>>>> inconsistent filesystems, which could cause "data theft"
>>>> above.
>>>
>>> Yes, I've seen you mentioning this case earlier in this thread. But let me
>>> say I consider it rather contrived :). For the container usecase if you are
>>> fetching say a root fs image and don't trust the content of the image, then
>>> how do you know it doesn't contain a malicious code that sends all the
>>> sensitive data to some third party? So I believe the owner of the container
>>> has to trust the content of the image, otherwise you've already lost.
>>>
>>> The container environment *provider* doesn't necessarily trust either the
>>> container owner or the image so they need to make sure their infrastructure
>>> isn't compromised by malicious actions from these - and for that either
>>> your immutable image scheme or FUSE mounting works.
>>>
>>> Similarly with the USB drive content. Either some malicious actor plugs USB
>>> drive into a laptop, it gets automounted, and that must not crash the
>>> kernel or give attacker more priviledge - but that's all - no data is
>>> stored on the drive. Or I myself plug some not-so-trusted USB drive to my
>>> laptop to read some content from it or possibly put there some data for a
>>> friend - again that must not compromise my machine but I'd be really dumb
>>> and already lost the security game if I'd put any sensitive data to such
>>> drive. And for this USB drive case FUSE mounting solves these problems
>>> nicely.
>>>
>>> So in my opinion for practical usecases the FUSE solution addresses the
>>> real security concerns.
>>>
>>> 								Honza
>>
>> I agree, *if* the FUSE filesystem is strongly sandboxed so it cannot
>> mess with things like my home directory.  Personally, I would run
>> the FUSE filesystem in a VM but that's a separate concern.
>>
>> There are also (very severe) concerns about USB devices *specifically*.
>> These are off-topic for this discussion, though.
>>
>> Of course, the FUSE filesystem must be mounted with nosuid, nodev,
>> and nosymfollow.  Otherwise there are lots of attacks possible.
>>
>> Finally, it is very much possible to use storage that one does not have
>> complete trust in, provided that one uses cryptography to ensure that
>> the damage it can do is limited.  Many backup systems work this way.
> 
> In brief, as I said, that is _not_ always a security concern:
> 
>   - If you don't fsck, and FUSE mount it, your write data to that
>     filesystem could be lost if the writable filesystem is
>     inconsistent;

In the applications I am thinking of, one _hopes_ that the filesystem
is consistent, which it almost always will be.  However, one wants
to be safe in the unlikely case of it being inconsistent.

>   - But if you fsck in advance and the filesystem, the kernel
>     implementation should make sure they should fix all bugs of
>     consistent filesystems.
> 
> So what's the meaning of "no fsck" here if you cannot write
> anything in it with FUSE approaches.

FUSE can (and usually does) have write support.  Also, fsck does not
protect against TOCTOU attacks.
-- 
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 --]