public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Demi Marie Obenour <demiobenour@gmail.com>,
	"Darrick J. Wong" <djwong@kernel.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel@vger.kernel.org,
	Joanne Koong <joannelkoong@gmail.com>,
	John Groves <John@groves.net>, Bernd Schubert <bernd@bsbernd.com>,
	Amir Goldstein <amir73il@gmail.com>,
	Luis Henriques <luis@igalia.com>,
	Horst Birthelmer <horst@birthelmer.de>,
	Gao Xiang <xiang@kernel.org>,
	lsf-pc@lists.linux-foundation.org
Subject: Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more
Date: Sun, 22 Mar 2026 13:30:33 +0800	[thread overview]
Message-ID: <24adea39-8b50-4765-8800-8937f2e23dc3@linux.alibaba.com> (raw)
In-Reply-To: <b30397b4-df0d-4f96-89a6-9c90aad10bd6@gmail.com>



On 2026/3/22 13:13, Demi Marie Obenour wrote:
> On 3/22/26 00:51, 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.
> 
> That makes sense!  Is this because the reads are at least
> deterministic?

I read the remaining parts, I think only this one that
needs to be clarified.

As I said in the letest reply, I don't think __simple__ is
a suitable descriptive word.

The fact is

A filesystem need to provide users enough information about
files and filesystem hierarchy, otherwise it shouldn't be
called as filesystems.

That is the only thing that immutable filesystem do, providing
filesystem information to vfs, that is all.

No simpler than that, it's the minimal feature set of a
filesystem (and comparing the slight on-disk difference
means nothing unless the on-disk design is too bad). And
I think that should answer your question.

Thanks,
Gao Xiang

  reply	other threads:[~2026-03-22  5:30 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <aYIsRc03fGhQ7vbS@groves.net>
2026-02-02 13:51 ` [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more Miklos Szeredi
2026-02-02 16:14   ` Amir Goldstein
2026-02-03  7:55     ` Miklos Szeredi
2026-02-03  9:19       ` [Lsf-pc] " Jan Kara
2026-02-03 10:31         ` Amir Goldstein
2026-02-04  9:22       ` Joanne Koong
2026-02-04 10:37         ` Amir Goldstein
2026-02-04 10:43         ` [Lsf-pc] " Jan Kara
2026-02-06  6:09           ` Darrick J. Wong
2026-02-21  6:07             ` Demi Marie Obenour
2026-02-21  7:07               ` Darrick J. Wong
2026-02-21 22:16                 ` Demi Marie Obenour
2026-02-23 21:58                   ` Darrick J. Wong
2026-02-04 20:47         ` Bernd Schubert
2026-02-06  6:26         ` Darrick J. Wong
2026-02-03 10:15     ` Luis Henriques
2026-02-03 10:20       ` Amir Goldstein
2026-02-03 10:38         ` Luis Henriques
2026-02-03 14:20         ` Christian Brauner
2026-02-03 10:36   ` Amir Goldstein
2026-02-03 17:13   ` John Groves
2026-02-04 19:06   ` Darrick J. Wong
2026-02-04 19:38     ` Horst Birthelmer
2026-02-04 20:58     ` Bernd Schubert
2026-02-06  5:47       ` Darrick J. Wong
2026-02-04 22:50     ` Gao Xiang
2026-02-06  5:38       ` Darrick J. Wong
2026-02-06  6:15         ` Gao Xiang
2026-02-21  0:47           ` Darrick J. Wong
2026-03-17  4:17             ` Gao Xiang
2026-03-18 21:51               ` Darrick J. Wong
2026-03-19  8:05                 ` Gao Xiang
2026-03-22  3:25                 ` Demi Marie Obenour
2026-03-22  3:52                   ` Gao Xiang
2026-03-22  4:51                   ` Gao Xiang
2026-03-22  5:13                     ` Demi Marie Obenour
2026-03-22  5:30                       ` Gao Xiang [this message]
2026-03-23  9:54                     ` [Lsf-pc] " Jan Kara
2026-03-23 10:19                       ` Gao Xiang
2026-03-23 11:14                         ` Jan Kara
2026-03-23 11:42                           ` Gao Xiang
2026-03-23 12:01                             ` Gao Xiang
2026-03-23 14:13                               ` Jan Kara
2026-03-23 14:36                                 ` Gao Xiang
2026-03-23 14:47                                   ` Jan Kara
2026-03-23 14:57                                     ` Gao Xiang
2026-03-24  8:48                                     ` Christian Brauner
2026-03-24  9:30                                       ` Gao Xiang
2026-03-24  9:49                                         ` Demi Marie Obenour
2026-03-24  9:53                                           ` Gao Xiang
2026-03-24 10:02                                             ` Demi Marie Obenour
2026-03-24 10:14                                               ` Gao Xiang
2026-03-24 10:17                                                 ` Demi Marie Obenour
2026-03-24 10:25                                                   ` Gao Xiang
2026-03-24 11:58                                       ` Demi Marie Obenour
2026-03-24 12:21                                         ` Gao Xiang
2026-03-26 14:39                                           ` Christian Brauner
2026-03-26 15:10                                             ` Gao Xiang
2026-03-26 16:11                                               ` Gao Xiang
2026-03-26 16:24                                                 ` Amir Goldstein
2026-03-26 16:37                                                   ` Gao Xiang
2026-03-23 12:08                           ` Demi Marie Obenour
2026-03-23 12:13                             ` Gao Xiang
2026-03-23 12:19                               ` Demi Marie Obenour
2026-03-23 12:30                                 ` Gao Xiang
2026-03-23 12:33                                   ` Gao Xiang
2026-03-22  5:14                   ` Gao Xiang
2026-03-23  9:43                     ` [Lsf-pc] " Jan Kara
2026-03-23 10:05                       ` Gao Xiang
2026-03-23 10:14                         ` Jan Kara
2026-03-23 10:30                           ` Gao Xiang
2026-02-04 23:19     ` Gao Xiang
2026-02-05  3:33     ` John Groves
2026-02-05  9:27       ` Amir Goldstein
2026-02-06  5:52         ` Darrick J. Wong
2026-02-06 20:48           ` John Groves
2026-02-07  0:22             ` Joanne Koong
2026-02-12  4:46               ` Joanne Koong
2026-02-21  0:37                 ` Darrick J. Wong
2026-02-26 20:21                   ` Joanne Koong
2026-03-03  4:57                     ` Darrick J. Wong
2026-03-03 17:28                       ` Joanne Koong
2026-02-20 23:59             ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24adea39-8b50-4765-8800-8937f2e23dc3@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=John@groves.net \
    --cc=amir73il@gmail.com \
    --cc=bernd@bsbernd.com \
    --cc=demiobenour@gmail.com \
    --cc=djwong@kernel.org \
    --cc=horst@birthelmer.de \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=luis@igalia.com \
    --cc=miklos@szeredi.hu \
    --cc=xiang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox