Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: How secure are temp files created via tempfile.TemporaryFile()?

18 views
Skip to first unread message

MRAB

unread,
Feb 18, 2010, 2:33:11 PM2/18/10
to pytho...@python.org
pyt...@bdurham.com wrote:
> I'm doing a code review of an application that occassionally writes
> blocks of secure data to temp files created with tempfile.TemporaryFile(
> delete=True ).
>
> How secure are temp files created via tempfile.TemporaryFile( delete=True )?
>
> Are there OS specific nuances I should be concerned about regarding use
> of this function on Windows (XP or higher) or Linux?
>
Well, the contents of temp files aren't encrypted, if that's what you're
asking, so if you're writing unencrypted data to a temp file then other
applications could read it.

pyt...@bdurham.com

unread,
Feb 18, 2010, 3:09:28 PM2/18/10
to pytho...@python.org, MRAB
MRAB,

> Well, the contents of temp files aren't encrypted, if that's what you're asking

I understand the contents of temp files aren't encrypted.

> if you're writing unencrypted data to a temp file then other applications could read it.

That's my concern - can other applications really read my temp files
created with tempfile.TemporaryFile( delete=True )?

I don't think so because:

1. These files appear to be exclusively locked by my process, eg. no
other processes can read or write to these temp files except the process
that created these files.

2. As soon as my process terminates (voluntarily or involuntarily), the
temp file gets deleted.

But I want to make sure.

Thanks,
Mal

Steven D'Aprano

unread,
Feb 18, 2010, 7:36:00 PM2/18/10
to
On Thu, 18 Feb 2010 15:09:28 -0500, python wrote:

> That's my concern - can other applications really read my temp files
> created with tempfile.TemporaryFile( delete=True )?


>>> import tempfile
>>> x = tempfile.TemporaryFile(delete=True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: TemporaryFile() got an unexpected keyword argument 'delete'


The Fine Manual has good information about the security of the various
calls:

http://docs.python.org/library/tempfile.html

tempfile.TemporaryFile(...)
Return a file-like object that can be used as a temporary
storage area. ... your code should not rely on a temporary file
created using this function having or not having a visible name
in the file system. ...

tempfile.NamedTemporaryFile(...)
This function operates exactly as TemporaryFile() does, except
that the file is guaranteed to have a visible name in the file
system ... Whether the name can be used to open the file a
second time, while the named temporary file is still open, varies
across platforms...


> I don't think so because:
>
> 1. These files appear to be exclusively locked by my process, eg. no
> other processes can read or write to these temp files except the process
> that created these files.

Exclusive locks are advisory, not mandatory, on some operating systems,
so you can't rely on it. Recent versions of Windows have an interface to
allow "backup software" to read files opened in exclusive mode, and I
believe that the kernel can read *and write* to open files (although I
welcome correction).

http://en.wikipedia.org/wiki/File_locking

And naturally, if your system is compromised with a root kit, then you
can't trust *anything*, including file locks. But nobody expects an
application to take responsibility for working securely in the face of a
root kit :)


> 2. As soon as my process terminates (voluntarily or involuntarily), the
> temp file gets deleted.
>
> But I want to make sure.


I think the best practice is platform-dependent:


if os.name = "posix": # Unix, Linux, OpenBSD, FreeBSD, ...
tmpfile = tempfile.TemporaryFile
delete = None
elif os.name in ["nt", "ce"]: # Windows NT, XP, 2000, CE, ...
tmpfile = tempfile.NamedTemporaryFile
delete = True
else:
# FIXME What to do for Mac, OS/2, RiscOS, Java?
tmpfile = tempfile.TemporaryFile
delete = None
if delete is not None:
f = tmpfile(*args, delete=delete)
else:
f = tmpfile(*args)


--
Steven

pyt...@bdurham.com

unread,
Feb 18, 2010, 11:19:41 PM2/18/10
to Steven D'Aprano, pytho...@python.org
Steven,

Thank you very much for your wonderful reply!!

I had read the Fine Manual, but as you pointed out the documentation
only mentions visibility of file names.

> Exclusive locks are advisory, not mandatory, on some operating systems, so you can't rely on it.

That comment and your list of OS specific behaviors were EXACTLY the
type of information I was looking for.

Thanks again!
Malcolm

Message has been deleted

Steven D'Aprano

unread,
Feb 19, 2010, 12:52:03 AM2/19/10
to
On Thu, 18 Feb 2010 21:34:58 -0800, Dennis Lee Bieber wrote:

> On Thu, 18 Feb 2010 15:09:28 -0500, pyt...@bdurham.com declaimed the
> following in gmane.comp.python.general:


>
>> 2. As soon as my process terminates (voluntarily or involuntarily), the
>> temp file gets deleted.
>>

> Which only means the directory entry for it is lost... depending
on
> the OS, someone creating a new file in "w+" and performing a long seek
> just to write one byte, may now have all those disk sectors your temp
> file had been in -- and can read them at leisure.
>
> Or some file recovery tools might make a file out of the
sectors...
>
> If you are really worried about the contents becoming visible
after
> "deletion" you should probably run a wipe operation on the file (write
> random sequence over data; read/verify said random sequence; write new
> random sequence over file; read/verify this sequence; write 1s
> complement of sequence; read/verify that final sequence).


If that is your concern, then you shouldn't be using tempfile, you should
be using permanent files and wiping them yourself.

I think the OP is more concerned about the sort of security flaw where
you open a temporary file, and some hostile process hijacks it before
you're done with it. But once you're done with the file, you probably no
longer care about the contents.


--
Steven

0 new messages