linux-kernel - Re: [PATCH v2 2/2] fat: always use dir_emit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 27 Jun 2024 05:10:44 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Thadeu Lima de Souza Cascardo <cascardo@...lia.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Gwendal
 Grignou <gwendal@...omium.org>, dlunev@...omium.org
Subject: Re: [PATCH v2 2/2] fat: always use dir_emit_dots and ignore . and
 .. entries

Thadeu Lima de Souza Cascardo <cascardo@...lia.com> writes:

>> Unacceptable to change the correct behavior to broken format. And
>> unlikely break the userspace, however this still has the user visible
>> change of seek pos.
>> 
>> Thanks.
>> 
>
> I agree that if this breaks userspace with a good filesystem or regresses
> in a way that real applications would break, that this needs to be redone.
>
> However, I spent a few hours doing some extra testing (I had already run
> some xfstests that include directory testing) and I failed to find any
> issues with this fix.
>
> If this would break, it would have broken the root directory. In the case
> of a directory including the . and .. entries, the d_off for the .. entry
> will be set for the first non-dot-or-dotdot entry. For ., it will be set as
> 1, which, if used by telldir (or llseek), will emit the .. entry, as
> expected.
>
> For the case where both . and .. are absent, the first real entry will have
> d_off as 2, and it will just work.
>
> So everything seems to work as expected. Do you see any user visible change
> that would break any applications?

First of all, I'm not thinking this is the fix, I'm thinking this as the
workaround of broken formatter (because the windows's fsck also think it
as broken). So very low priority to support.

As said, I also think low chance to break the userspace. However it
changes real offset to pseudo offset. So if userspace saved it to
persistent space, breaks userspace. Unlikely, but I think there is no
value to change the behavior for workaround.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>