Message-ID: <CAKYAXd9fjSEsNDLMtqpWOcu9xWdFzr1gqLdC5aKJFmgK9MfHoA@mail.gmail.com>
Date:   Mon, 13 Dec 2021 23:09:44 +0900
From:   Namjae Jeon <linkinjeon@...nel.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Adam Borowski <kilobyte@...band.pl>, Sean Young <sean@...s.org>,
        Sungjong Seo <sj1557.seo@...sung.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Incorrect handling of . and .. files

2021-12-13 20:39 GMT+09:00, Pali Rohár <pali@...nel.org>:
> On Monday 13 December 2021 07:47:44 Adam Borowski wrote:
>> On Sat, Dec 11, 2021 at 03:04:53AM +0100, Pali Rohár wrote:
>> > I tried to find some information what is allowed and what not.
>> >
>> > On Monday 27 September 2021 12:19:48 Sean Young wrote:
>> > > Windows allows files and directories called "." and ".." to be
>> > > created
>> > > using UNC paths, i.e. "\\?\D:\..". Now this is totally insane
>> > > behaviour,
>> > > but when an exfat filesytem with such a file is mounted on Linux,
>> > > those
>> > > files show up as another directory and its contents is inaccessible.
>> > >
>> > > I can replicate this using exfat filesystems, but not ntfs.
>> >
>> > Microsoft exFAT specification explicitly disallow "." and "..", see:
>> [...]
>> > On the other hand Microsoft FAT32 specification can be understood that
>> > file may have long name (vfat) set to "." or ".." but not short name.
>> [...]
>> > OSTA UDF 2.60 specification does not disallow "." and ".." entries, but
>> [...]
>> > So it means that "." and ".." entries could be stored on disk as valid
>> > file names.
>>
>> It doesn't matter one whit what the specification says.  Anyone with a
>> disk
>> editor can craft a filesystem containing filenames such as "." or "..",
>> "/"
>> "foo/bar" or anything else we would like to ban.
>
> That is truth. But question is what should do fsck tools with such file
> names on filesystems where "." and ".." are permitted? Fully valid
> argument is "do not touch them" because there is nothing bad with these
> names.
>
>> > > So, in Linux cannot read "." or ".." (i.e., I can't see "Hello,
>> > > World!"). I
>> > > don't know what the correct handling should be, but having two "." and
>> > > two
>> > > ".." files does not seem right at all.
>> >
>> > This is really a bug in Linux kernel. It should not export "." and ".."
>> > into VFS even when filesystem disk format supports such insane file
>> > names.
>>
>> This.
>>
>> Otherwise, every filesystem driver would need to contain redundant code
>> for
>> checking for such bad names.
>>
>> > So either Linux needs to completely hide these insane file names from
>> > VFS or translate them to something which do not conflict with other
>> > files in correct directory.
>>
>> Escaping bad names has the problem of the escaped name also possibly
>> existing -- perhaps even recursively.  Plus, the filesystem might be
>> using
>> hashed or tree indices which could go wrong if a name is altered.
>
> vfat has already own escaping scheme and it is documented in mount(8)
> manpage. Invalid characters are translated either to fixed char '?' or
> to ':'... esc sequence if uni_xlate mount option is used. But it looks
> like that that kernel vfat driver do not have these two entries "." and
> ".." in its blacklist.
>
> And, another important thing about vfat is that it has two file names
> for each file. One short 8.3 and one long vfat. Short 8.3 do not allow
> "." or "..", so another possibility how to handle this issue for vfat is
> to show short 8.3 name in VFS when long is invalid.
>
> For UDF case, specification already says how to handle problematic
> file names, so I think that udf.ko could implement it according to
> specification.
>
> But for all other filesystems it is needed to do something ideally on
> VFS layer.
>
> What about generating some deterministic / predicable file names which
> will not conflict with other file names in current directory for these
> problematic files?
>
>> But then, I once proposed (and I'm pondering reviving) a ban for
>> characters
>> \x01..\x1f and possibly others, and if banned, they can still
>> legitimately
>> occur in old filesystems.
>>
>> > I guess that hiding them for exfat is valid thing as Microsoft
>> > specification explicitly disallow them. Probably fsck.exfat can be
>> > teach
>> > to rename these files and/or put them to lost+found directory.
>>
>> fsck fixing those is a good thing but we still need to handle them at
>> runtime.
>
> Namjae Jeon, would you be able to implement fixing of such filenames in
> fsck.exfat tool?
We've recently been finalizing the repair function in fsck.exfat. We
will check it as soon as it is finished.

Thanks for your suggestion!
>
>>
>> Meow!
>> --
>> ⢀⣴⠾⠻⢶⣦⠀
>> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were
>> good.
>> ⢿⡄⠘⠷⠚⠋⠀                                       -- <willmore> on
>> #linux-sunxi
>> ⠈⠳⣄⠀⠀⠀⠀
>

Powered by blists - more mailing lists