Does This Scare You?

[Jon Ribbens]

On 2016-08-22, Steve D'Aprano <steve+python at pearwood.info> wrote:
> On Mon, 22 Aug 2016 09:50 pm, Jon Ribbens wrote:
>> I don't know what purpose you are envisaging this function being used
>> for, but the only one I can think of is input sanitisation. e.g. a web
>> form where you receive a file from the Internet and store it somewhere,
>> and you want to use the filename given to you rather than choose your
>> own randomly-generated one.
>> 
>> Under Unix all you need to do is check for the filename starting with
>> "." or containing "/." (or "/", depending on your requirements).
>> Under Windows you would use this function, which apparently doesn't
>> work, hence: security hole.
>
> That's backwards: it works under Windows, but is buggy under non-Windows.

I'm not sure what you're getting at there, but you appear to be wrong:

    C:\>python
    Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900
    32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import pathlib
    >>> pathlib.WindowsPath("con .txt").is_reserved()
    False

> For starters, even on Unix I probably wouldn't want to
> use "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\.txt" as a
> file name, even if it is technically legal.

That might be your personal preference, but it's not a security hole
per se.

> No, not at all. I can't assume that just because a file name is legal that I
> can write to it. Even after sanitising the name (or deciding I don't need
> to bother) I still need to be prepared to catch I/O errors when writing the
> file -- including attempts to write to reserved file names.

As mentioned by others, this is nothing to do with lack of error-checking.

> Technically that could be called a DoS attack, but the same could be said
> for ANY bug that raises an exception. I think that it takes more than that
> to be a security bug.

It doesn't raise an exception. It interacts with the hardware of the
server.