2021-12-13 20:39 GMT+09:00, Pali Rohár <pali@xxxxxxxxxx>: > 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 >> ⠈⠳⣄⠀⠀⠀⠀ >
