[Mono-dev] [PATCH] MS.NET compatible Path.GetTempFileName

[Kornél Pál]

Hi,

> I have no idea how on earth an application could depend on this specific
> pattern (without being completely pendantic and checking for .tmp). Did
> this issue happen with some real life app?

The actual issue I experienced is the fact that Path.GetTempFileName
implementation of Mono creates a file with no extension while MS.NET creates
a file with extension .tmp.

I am working on some Win32 resource file and resource table (in PE file)
generation framework that is compatible with MS cvtres.exe (that is used by
MS.NET SRE and compilers). cvtres.exe appends .res extension if the resource
file has no extension. This causes a bug in MS.NET in fact but as far as I
know Mono policy is to copy MS.NET bugs.

I experienced this bug when I used filenames generated by GetTempFileName.
They worked on MS.NET but failed on Mono.

I think format of temp file names may be and can be assumed as it is clearly
documented.
(http://msdn.microsoft.com/library/en-us/fileio/fs/gettempfilename.asp)

> What does msft do if you create all 64k files tmp0000.tmp to tmpffff.tmp?
> That sounds like a trivial DoS.

(Note that there is no zero padding so first file name is tmp0.tmp.) MS.NET
will throw an exception (IOException with ERROR_FILE_EXISTS) while Mono will
hang in an infinite loop. 32-bit integers can owerflow as well so it isn't a
protection agains DoS (of course I understand what you mean that a 16-bit
integer can overflow earlier but this is true for MS.NET as well). A correct
solution should avoid infinite loop anyway.

If you are interested in the actual result of this overflow run the attached
on MS.NET. It will finish in a reasonable time.

Also note that the behavior regarding this infinite loop is not affected by
my patch.

The only thing I cannot understand it the fact that if I submit a patch that
corrects an MS.NET bug in Mono it is rejected or isn't welcomed altought the
same is true for a patch that implements an MS.NET bug.

But note that this patch implements designed and documented behavior rather
than a bug.

Kornél

----- Original Message -----
From: "Ben Maurer" <bmaurer at ximian.com>
To: <kornelpal at hotmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Friday, January 06, 2006 8:44 PM
Subject: Re: [Mono-dev] [PATCH] MS.NET compatible Path.GetTempFileName


>> MS.NET uses Windows API GetTempFileName function for
>> Path.GetTempFileName. If we want full compatibility we should implement
>> it in the I/O layer using a global unsigned 16-bit counter that starts
>> from zero and is incremented without overflow check each time
>> GetTempFileName is called.
>
> I have no idea how on earth an application could depend on this specific
> pattern (without being completely pendantic and checking for .tmp). Did
> this issue happen with some real life app?
>
>> Altough a managed implementation can be as good as a native one I think
>> the file name pattern should be the same. The attached patch modifies
>> the pattern to "tmp<UUUU>.tmp" that is the same used by MS.NET. (There
>> is no zero padding in <UUUU>.)
>
> What does msft do if you create all 64k files tmp0000.tmp to tmpffff.tmp?
> That sounds like a trivial DoS.
>
> -- Ben
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GetTempFileNameOverflow.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060106/9d475886/attachment.pl