[cfe-dev] Clang violates the mkstemp() contract?
Kees van Reeuwijk
reeuwijk at few.vu.nl
Wed Jul 14 12:59:39 PDT 2010
On 14 Jul 2010, at 21:09, Török Edwin wrote:
> The file should probably not be removed at all. If there is concern
> that the file stays there after process exit, it should be added to
> removeFileOnSignal.
Well, clang is actually not interested in that particular file, because it wants to append a .o or .s after the filename that was generated. That makes the cleanup a bit trickier.
Also, clang uses mktemp() if mkstemp() is not available on a particular platform, and in that case clang should actively create the file as soon as it gets the name.
>
>
>>
>> Which seems to confirm that an unwarranted assumption is made.
>>
>> The reason this works on many platforms is because there the unique
>> filename is generated by first attempting to use a name based on a
>> random number. If a file with that name exists, the name is then
>> modified to avoid existing names. However, on Minix the first attempt
>> uses the process id, so you'll always get the same temporary filename
>> if the previous ones do not exist (any more), on other platforms that
>> is far less likely (but not impossible).
>
> Sounds like mkstemp() on Minix is fairly predictable then.
That's correct, but if you're implying that that is a security concern: AFAIK mkstemp() is supposed to be an atomic operation and therefore predictability is not a concern.
--
Kees van Reeuwijk
More information about the cfe-dev
mailing list