Re: [PATCH maint 0/3] do not write files outside of work-dir

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Jun 1, 2011, 06:31 UTC
Message-ID: <4DE5DCDD.4020303@viscovery.net>
In-Reply-To: <20110601041439.GH29958@ece.pdx.edu>

Am 6/1/2011 6:14, schrieb Tait:

Show 6 quoted lines

>> Theo Niessink has uncovered a serious sercurity issue in Git for Windows,
>> where cloning an evil repository can arbitrarily overwrite files outside
>> the repository...
> 
> Filenames starting with C: are not necessarily absolute. Consider
> "c:foo.txt" where c: is the current directory on drive C, or

We have a different notion of "absolute path". This one *is* absolute per our definition. See below.

> "c:stream1" where c is a single-letter filename in the current directory
> with an alternate data stream such as would be shown by dir /r. The

On my system, this does not create a file in the current directory with an alternate data stream, but - while the working directory is somewhere on drive D - a file is created on drive C.

Show 11 quoted lines

> has_dos_drive_prefix check is overly broad. Maybe this is intentional and
> just needs to be documented. Absolute paths like \\localhost\C$\file.txt
> and \\?\C:\file.txt do seem to be caught, because they start with '\'.
> 
> Microsoft says[1] a path is relative unless:
>   - it begins with "\\"
>   - it begins with a disk designator followed by a directory separator
>   - it begins with a single "\"
> 
> On that basis, has_dos_drive_prefix(path) should be:
>   isalpha(*(path)) && (path)[1] == ':' && is_dir_sep((path)[2])

This is not the definition of "relative path" that we are interested in. Let $PWD be the current directory. For our purposes, a path $P is relative if $P and $PWD/$P designate the same file system entry. Otherwise, $P is an absolute path.

With this definition, the current has_dos_drive_prefix() is good enough.

> However, there are also paths within the NT namespace (as opposed to the
> Win32 namespace, [1] again) that might be considered absolute, or at least
> to which git should not try to write. Examples would be PRN, CONOUT$, AUX,

For our purposes, these names are all relative paths. It's a case of "Doctor, it hurts when I stick my finger in my eye" if you have a repository with these names.

Note that git never writes to these files: It always first allocates a temporary file, eg. nul.123456; but this will already fail because these special file names are forbidden even when a file extension is attached.

-- Hannes