import os
os.tmpnam() RuntimeWarning: tmpnam is a potential security risk to your program
Are these runtime warnings necessary? Suppressing these warnings is a pita for one-off uses of os.tmpnam() or os.tempnam(). 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. Raymond --------------------------------- Happy FUN BALL! -only $14.95- Warning: Pregnant women, the elderly and children under 10 should avoid prolonged exposure to Happy Fun Ball. Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds. Happy Fun Ball Contains a liquid core, which, if exposed due to rupture, should not be touched, inhaled, or looked at. Do not use Happy Fun Ball on concrete. Discontinue use of Happy Fun Ball if any of the following occurs: Itching, Vertigo, Dizziness Tingling in extremities, Loss of balance or coordination Slurred speech, Temporary blindness, Profuse sweating, Heart palpitations If Happy Fun Ball begins to smoke, get away immediately. Seek shelter and cover head. Happy Fun Ball may stick to certain types of skin. When not in use, Happy Fun Ball should be returned to its special container and kept under refrigeration... Failure to do so relieves the makers of Happy Fun Ball, Wacky Products Incorporated, and its parent company Global Chemical Unlimited, of any and all liability. Ingredients of Happy Fun Ball include an unknown glowing substance which fell to Earth, presumably from outer space. Happy Fun Ball has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq. Do not taunt Happy Fun Ball. Happy Fun Ball comes with a lifetime guarantee. Happy Fun Ball ACCEPT NO SUBSTITUTES!
On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger <python@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
Hello,
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.
They have been removed in 3.0.
Why does Python offer this attractive nuisance?
Well, there was a time when security concerns were a lot less wide-spread. Regards Antoine.
Hello, Dne Thursday 05 February 2009 Antoine Pitrou napsal(a):
Hello,
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.
They have been removed in 3.0.
What's the replacement in the library then, in case that I just want to create a unique file name and I don't care about the possible issues?
Why does Python offer this attractive nuisance?
Well, there was a time when security concerns were a lot less wide-spread.
Is using of virtual memory secure? Aren't we all adults suddenly? ;-) I know, the damage has already been done (as with cmp parameter of sort(ed) etc.) and I should have notice them sooner. Or it is only me, maybe, who thinks that such weight losing is not healthy for the language and library users. Regards, JP
Jaroslav Pachola <pachola <at> mageo.cz> writes:
What's the replacement in the library then, in case that I just want to create a unique file name and I don't care about the possible issues?
Three alternatives I'm thinking of: - tempfile.mktemp(): the doc says it has been deprecated since 2.3, but it's still there; - NamedTemporaryFile(delete=False): that's the officially suggested replacement in the doc; - tempfile.mkdtemp() and then create a regular file in the created directory. Regards Antoine.
Looking at the UNARY_NOT case in ceval.c: case UNARY_NOT: v = TOP(); err = PyObject_IsTrue(v); Py_DECREF(v); if (err == 0) { Py_INCREF(Py_True); SET_TOP(Py_True); continue; } else if (err > 0) { Py_INCREF(Py_False); SET_TOP(Py_False); err = 0; continue; } STACKADJ(-1); break; I don't understand why there's a STACKADJ(-1) at its end. Looking at the code, we know that if the CPU arrives to the STACKADJ, it's because of an error condition in the PyObject_IsTrue that sets err to a < 0 value, so exiting the big switch statement, an error will be raised. So the question is, why there's the need to skip the top stack PyObject? It's a different behaviour comparing it to the all other unary operators. For example: case UNARY_NEGATIVE: v = TOP(); x = PyNumber_Negative(v); Py_DECREF(v); SET_TOP(x); if (x != NULL) continue; break; There's no STACKADJ instruction on errors. Can someone explain it? Thanks a lot Cesare
It's to make up for the lack of SET_TOP in that path. On Thu, Feb 5, 2009 at 10:19 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote:
Looking at the UNARY_NOT case in ceval.c:
case UNARY_NOT: v = TOP(); err = PyObject_IsTrue(v); Py_DECREF(v); if (err == 0) { Py_INCREF(Py_True); SET_TOP(Py_True); continue; } else if (err > 0) { Py_INCREF(Py_False); SET_TOP(Py_False); err = 0; continue; } STACKADJ(-1); break;
I don't understand why there's a STACKADJ(-1) at its end. Looking at the code, we know that if the CPU arrives to the STACKADJ, it's because of an error condition in the PyObject_IsTrue that sets err to a < 0 value, so exiting the big switch statement, an error will be raised.
So the question is, why there's the need to skip the top stack PyObject? It's a different behaviour comparing it to the all other unary operators. For example:
case UNARY_NEGATIVE: v = TOP(); x = PyNumber_Negative(v); Py_DECREF(v); SET_TOP(x); if (x != NULL) continue; break;
There's no STACKADJ instruction on errors.
Can someone explain it?
Thanks a lot
Cesare _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
Antoine Pitrou -
Cesare Di Mauro -
Guido van Rossum -
Jaroslav Pachola -
Jean-Paul Calderone -
Raymond Hettinger