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

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?

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

Powered by blists - more mailing lists