linux-kernel - Incorrect handling of . and .. files

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-next>] [day] [month] [year] [list]

Message-ID: <20210927111948.GA16257@gofer.mess.org>
Date:   Mon, 27 Sep 2021 12:19:48 +0100
From:   Sean Young <sean@...s.org>
To:     Namjae Jeon <linkinjeon@...nel.org>,
        Sungjong Seo <sj1557.seo@...sung.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Incorrect handling of . and .. files

Hi,

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.

This is what I did on Windows using rust:

	use std::fs::File;
	use std::io::Write;

	fn main() {
	    let mut file =
		File::create(r"\\?\D:\..").expect("create dot file");
	    file.write_all(b"Hello, world!").expect("write dot file");
	}

Now on Linux (I also created a file called ".").

[root@...oleh tmp]# mount -t exfat /dev/loop0p1 /mnt
[root@...oleh tmp]# cd /mnt
[root@...oleh mnt]# ls -la
total 20
drwxr-xr-x. 5 root root 4096 Sep 27 11:47  .
drwxr-xr-x. 5 root root 4096 Sep 27 11:47  .
dr-xr-xr-x. 1 root root  176 Sep 21 11:05  ..
dr-xr-xr-x. 1 root root  176 Sep 21 11:05  ..
drwxr-xr-x. 2 root root 4096 Sep 27  2021 '$RECYCLE.BIN'
drwxr-xr-x. 2 root root 4096 Sep 27  2021 'System Volume Information'

Microsoft says this:

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

	Because it turns off automatic expansion of the path string, the
	"\\?\" prefix also allows the use of ".." and "." in the path names,
	which can be useful if you are attempting to perform operations on a
	file with these otherwise reserved relative path specifiers as part of
	the fully qualified path.

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.

Thanks,
Sean