Message-ID: <87ldn62kjy.fsf@mailhost.krisman.be>
Date: Tue, 26 Aug 2025 11:02:09 -0400
From: Gabriel Krisman Bertazi <krisman@...e.de>
To: Amir Goldstein <amir73il@...il.com>
Cc: André Almeida <andrealmeid@...lia.com>,  Miklos Szeredi
 <miklos@...redi.hu>,  Theodore Tso <tytso@....edu>,
  linux-unionfs@...r.kernel.org,  linux-kernel@...r.kernel.org,
  linux-fsdevel@...r.kernel.org,  Alexander Viro <viro@...iv.linux.org.uk>,
  Christian Brauner <brauner@...nel.org>,  Jan Kara <jack@...e.cz>,
  kernel-dev@...lia.com
Subject: Re: [PATCH v6 4/9] ovl: Create ovl_casefold() to support casefolded
 strncmp()

Amir Goldstein <amir73il@...il.com> writes:

> On Tue, Aug 26, 2025 at 3:34 AM Gabriel Krisman Bertazi <krisman@...e.de> wrote:
>
>>
>> I was thinking again about this and I suspect I misunderstood your
>> question.  let me try to answer it again:
>>
>> Ext4, f2fs and tmpfs all allow invalid utf8-encoded strings in a
>> casefolded directory when running on non-strict-mode.  They are treated
>> as non-encoded byte-sequences, as if they were seen on a case-Sensitive
>> directory.  They can't collide with other filenames because they
>> basically "fold" to themselves.
>>
>> Now I suspect there is another problem with this series: I don't see how
>> it implements the semantics of strict mode.  What happens if upper and
>> lower are in strict mode (which is valid, same encoding_flags) but there
>> is an invalid name in the lower?  overlayfs should reject the dentry,
>> because any attempt to create it to the upper will fail.
>
> Ok, so IIUC, one issue is that return value from ovl_casefold() should be
> conditional to the sb encoding_flags, which was inherited from the
> layers.

yes, unless you reject mounting strict_mode filesystems, which the best
course of action, in my opinion.

>
> Again, *IF* I understand correctly, then strict mode ext4 will not allow
> creating an invalid-encoded name, but will strict mode ext4 allow
> it as a valid lookup result?

strict mode ext4 will not allow creating an invalid-encoded name. And
even lookups will fail.  Because the kernel can't casefold it, it will
assume the dirent is broken and ignore it during lookup.

(I just noticed the dirent is ignored and the error is not propagated in
ext4_match.  That needs improvement.).

>>
>> André, did you consider this scenario?
>
> In general, as I have told Andre from v1, please stick to the most common
> configs that people actually need.
>
> We do NOT need to support every possible combination of layers configurations.
>
> This is why we went with supporting all-or-nothing configs for casefolder dirs.
> Because it is simpler for overlayfs semantics and good enough for what
> users need.
>
> So my question is to you both: do users actually use strict mode for
> wine and such?
> Because if they don't I would rather support the default mode only
> (enforced on mount)
> and add support for strict mode later per actual users demand.

I doubt we care.  strict mode is a restricted version of casefolding
support with minor advantages.  Basically, with it, you can trust that
if you update the unicode version, there won't be any behavior change in
casefolding due to newly assigned code-points.  For Wine, that is
irrelevant.

You can very well reject strict mode and be done with it.

>
>> You can test by creating a file
>> with an invalid-encoded name in a casefolded directory of a
>> non-strict-mode filesystem and then flip the strict-mode flag in the
>> superblock.  I can give it a try tomorrow too.
>
> Can the sb flags be flipped in runtime? while mounted?
> I suppose you are talking about an offline change that requires
> re-mount of overlayfs and re-validate the same encoding flags on all layers?

No, it is set at mkfs-time.  The scenario I'm describing is a
filesystem corruption, where a filename has invalid characters but the
disk is in strict mode.  What I proposed is a way to test this by
crafting an image.

-- 
Gabriel Krisman Bertazi

Powered by blists - more mailing lists