Skip to contentSkip to conversation

NTFS code doesn't sanitize folder names sufficiently

BUG Marian Beermann 4 participants 4 messages Jul 26, 2012 – Aug 1, 2012 VFS

lore
Share & tools
lore
#0 lore raw

Hello everyone,

today I noticed some very odd behaviour, which could lead people to believe a loss of data, because it is possible to create directories with backslashes in them.

I am currently running kernel 3.5.

To completly reproduce the problem to the full extend you'll need a Windows computer, but to see whats wrong Linux completly suffices :-)

On a Linux computer
1. Create a directory named TestA on an NTFS partition
2. Create a subdirectory of TestA named TestB
3. Create a third directory alongside TestA named TestA\TestB (the fundamental problem is this: backslashes in directory names)

Connect the drive containing the NTFS partition now to a Windows computer and navigate to the directory containing TestA and TestA\TestB. If you navigate to the folder (not path!) TestA\TestB you'll actually see the contents of the path TestA\TestB (the subfolder TestB) and not the contents of the directory. It is not possible on a Windows machine to access the contents of the directory named TestA\TestB. This is not a bug in Windows, it's caused by a bug in the NTFS driver, which allows illegal characters.

The solution to this would be to disallow creation of files and folders on NTFS drives containing illegal characters.

Best regards
Marian Beermann

(notice: I'm not subscribed to linux-fsdevel...)

#1 lore raw
Quoted 13 lines · Marian Beermann

Hello everyone,

today I noticed some very odd behaviour, which could lead people to believe a loss of data, because it is possible to create directories with backslashes in them.

I am currently running kernel 3.5.

To completly reproduce the problem to the full extend you'll need a Windows computer, but to see whats wrong Linux completly suffices :-)

On a Linux computer
1. Create a directory named TestA on an NTFS partition
2. Create a subdirectory of TestA named TestB
3. Create a third directory alongside TestA named TestA\TestB (the fundamental problem is this: backslashes in directory names)

Quoted 7 lines

Connect the drive containing the NTFS partition now to a Windows computer and navigate to the directory containing TestA and TestA\TestB. If you navigate to the folder (not path!) TestA\TestB you'll actually see the contents of the path TestA\TestB (the subfolder TestB) and not the contents of the directory. It is not possible on a Windows machine to access the contents of the directory named TestA\TestB. This is not a bug in Windows, it's caused by a bug in the NTFS driver, which allows illegal characters.

The solution to this would be to disallow creation of files and folders on NTFS drives containing illegal characters.

Best regards
Marian Beermann

Yeah that's a tough one. I wouldn't exactly call it a bug. There's probably lots of stuff like this you could do that the command line would allow you to perform but not be a correct and intended function. I would put this down to user error rather than a bug. Anyone with knowledge of operating systems and file system structuring should know that / or \ are illegal characters for creating a directories. Whether it be on Windows or Linux.

Regards

Signature · 11 lines
		Chris Jones @ [email protected]
also on [email protected] and [email protected]

OpenSUSE 12.1 (IceWM/zsh) (PC)|Android 4.0.3 (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming)
Linux kernel developer|Solaris kernel developer|BSD kernel developer
Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services
Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick
Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox

PGP Fingerprint: 4E38 0776 B380 63C8 F64F
A7D6 736C CF56 42A4 FB35
#2 lore raw
In reply to Marian Beermann
Quoted 8 lines · Marian Beermann

Hello everyone,

today I noticed some very odd behaviour, which could lead people to believe a loss of data, because it is possible to create directories with backslashes in them.

I am currently running kernel 3.5.

Quoted 8 lines

To completly reproduce the problem to the full extend you'll need a Windows computer, but to see whats wrong Linux completly suffices :-)

On a Linux computer
1. Create a directory named TestA on an NTFS partition
2. Create a subdirectory of TestA named TestB
3. Create a third directory alongside TestA named TestA\TestB (the fundamental problem is this: backslashes in directory names)

If you're writing new directories to an NTFS partition, it's very probable that you're not actually using the in-kernel NTFS driver at all. It's more likely that you have the userspace (FUSE) NTFS driver instead:
http://www.tuxera.com/community/ntfs-3g-download/

In fact, they have a FAQ about it the issue that you're seeing:
http://www.tuxera.com/community/ntfs-3g-faq/#posixfilenames2
You use the 'windows_names' mount option to disable creating file and directory names that confuse windows.

Linux itself (and most native Linux programs) has no issues with directory names containing the '\' character, of course; the only characters that you cannot use are '/' and ASCII NUL, 0x00.

Signature · 1 line
Calvin Walton <[email protected]>
#3 lore raw
In reply to Marian Beermann
Quoted 3 lines

The solution to this would be to disallow creation of files and folders on NTFS drives containing illegal characters.

Illegal characters with respect to Windows & the like are different from Illegal characters with respect to the NTFS filesystem structure.

Looking at ntfs-3g(8) [yes, I'm aware that is a different driver that this bug is about], the section on Windows Filename Compatability says this:

[...] all characters are
allowed except '/' and '\0'. This is perfectly legal on Windows,
though some application may get
confused. The option windows_names may be used to apply Windows
restrictions to new file names.

To recap: no data will be lost due to using '\' in filenames. Some operating systems just may not be capable off accessing it.

--
Cody