Re: os.tmpname security risk?

[Patrick Donnelly <batrick@...>]

On Wed, Jul 13, 2011 at 8:47 PM, HyperHacker <hyperhacker@gmail.com> wrote:
> On Wed, Jul 13, 2011 at 18:40, Patrick Donnelly <batrick@batbytes.com> wrote:
>> On Wed, Jul 13, 2011 at 8:25 PM, HyperHacker <hyperhacker@gmail.com> wrote:
>>> True, you usually open the file immediately after creating it, but
>>> that leads to the potential security risk/race condition mentioned in
>>> the first post (and the reason os.tmpname() creates the file for you)
>>> - there is still a small window of opportunity (which an attacker
>>> might have various ways of enlarging) to sneak in and tamper with the
>>> file between the time you create it and the time you open it. (Or
>>> another app creates the same file, overwriting yours during that
>>> window - unlikely, but possible.)
>>
>> You appear confused. There is no "small window of opportunity" between
>> when the file is made and when you open it. In fact, the file is
>> created when it is opened (O_CREAT|O_EXCL). There is no opportunity
>> with those flags for someone to "sneak" in a fake version of the file.
>>
>> --
>> - Patrick Donnelly
>>
>>
>
> In that case, shouldn't os.tmpname() return a file object? The manual
> doesn't mention anything about opening the file for you, and actually
> says it needs to be explicitly opened before it can be used. So during
> the time between calling os.tmpname() and io.open() someone could
> theoretically remove the file, and perhaps substitute their own, if
> the permission system didn't prevent it.

Only root or another process with your uid would (should) be able to
remove the file. The security of the system relies on the file being
unreadable/unwritable by others. Files created by mkstemp are created
(*) with the 0600 permissions giving only the owner read/write rights.

(*) The UNIX standard does not require this AFAICT.

-- 
- Patrick Donnelly