[Python-Dev] Warnings (original) (raw)

Jean-Paul Calderone exarkun at divmod.com
Thu Feb 5 17:47:21 CET 2009

On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger <python at rcn.com> wrote:

import os

os.tmpnam() RuntimeWarning: tmpnam is a potential security risk to your program

This warning is a reflection of the fact that (at least) the glibc authors think you shouldn't be using tmpnam(2). If you compile a C program that uses it, you'll see a warning about it. Since you can write a Python program that uses tmpnam(2) without ever compiling such a C program, you get a RuntimeWarning instead. It's not quite analogous, since you don't get the warning from the C program every time you run it, but it's about as close as you can do in Python without resorting to crazy tricks.

Are these runtime warnings necessary? Suppressing these warnings is a pita for one-off uses of os.tmpnam() or os.tempnam().

Why are you using them? Why not just use one of the many, many, many other APIs for generating temporary files that Python exposes? One of the ones that doesn't emit any warnings?

I would hate for this sort of thing to propagate throughout the standard library. Some folks think eval() should never be used and the same for input(). Some folks think md5 should be removed. Some folks think pickles are the ultimate security threat. IMO, it is enough to note potential vulnerabilities in the docs. Even then, I'm not too keen on the docs being filled with lots of red-outlined pink-boxed warning signs, effectively communicating that Python itself is dangerous and unreliable.

I agree. The best thing to do would be to deprecate the Python wrappers around insecure C functions and then remove them after a couple releases. It's not as though these functions fill a critical niche - the tempfile module and even os.tmpfile are more than enough. Why does Python offer this attractive nuisance?

Jean-Paul

More information about the Python-Dev mailing list