Does This Scare You?

[eryk sun]

On Mon, Aug 22, 2016 at 4:18 PM, Chris Angelico <rosuav at gmail.com> wrote:
>
>> The CON device should work if the process is attached to a console
>> (i.e. a conhost.exe instance).
>
> No, I used Pike (to avoid any specifically-Python issues or
> protections) running in a console. Attempting to write to "Logs/con"
> wrote to the console, so I know the console device is active.
> Attempting to write to "Logs/con.txt" failed as described.

What version of Windows is this? If it's Windows 7 I'll have to check
that later. If "Logs" is an existing directory, then both "Logs/con"
and "Logs/con.txt" should refer to the console. If "Logs" doesn't
exist, then both should fail. Virtual DOS devices only exist in
existing directories.

>> > I wouldn't accept file names from untrusted sources on *any* system
>>
>> There are still desktop applications that ask users to name their files.
> If the user owns the computer, s/he should be allowed to attempt any
> name, and there'd simply be some that fail - same as any other invalid
> characters

Silently writing a file to a (possibly hidden) console or NUL device
is not the same thing as failing with an error. If users explicitly
open "NUL" or "\\.\NUL", I can detect that, and I have no problem with
it (with some reservations about the former). But if they open files
like "C:\Users\JoeUser\Documents\Nul.20160822.doc", I want to make
sure they know that they just asked to save to "\\.\NUL". It's not a
common problem. I just find the system's behavior abhorrent. I'd like
to have a manifest setting that opts the process out of this stupid
DOS legacy behavior.

> Windows won't let you put a colon or question mark in a file name, for instance,
> which annoys my brother no end when I give him files like
> "What's Up, Doc?.mkv" or "Operation: Rabbit.mkv")

A colon is reserved for NTFS streams, so it can silently bite you. If
you get an error for "Operation: Rabbit.mkv", you're probably using
FAT32. On NTFS that creates a file named "Operation" with a $DATA
stream named " Rabbit.mkv".

Every NTFS file has at least the anonymous stream, e.g.
"filename::$DATA". Every NTFS directory has at least the $I30 stream,
e.g. "dirname:$I30:$INDEX_ALLOCATION". Directories can also have named
$DATA streams.

As to question mark and other wildcard characters, those are all
unambiguously handled as exceptions. No Microsoft filesystem allows
them because wildcard matching is baked into the system, such as the
FileName parameter of NtQueryDirectoryFile when listing the contents
of a directory. I guess no one on the NT I/O team wanted to bother
with the possibility of escaping these wildcards since they weren't
allowed in DOS filenames.

FsRtlIsNameInExpression [1] is the kernel-mode filesystem function
that implements wildcard matching. Note that DOS wildcard semantics
are implemented by DOS_STAR (<), DOS_QM (>), and DOS_DOT (").
FindFirstFile has to convert DOS wildcard patterns to NT semantics
before calling NtQueryDirectoryFile. It's not as simple as
substituting the corresponding DOS_ wildcard.

Pipe and ASCII control characters are also reserved, except not in
NTFS stream names. Reserving pipe is just a DOS legacy. I don't think
it's used for anything internally.

> or over-long names or anything like that.

Good news. In Windows 10, systems and applications can opt in to using
long paths with up to about 32760 characters. Python 3.6 will be
opting in.

[1]: https://msdn.microsoft.com/en-us/library/ff546850