Every few months I receive patches that purport to make the tempfile module more secure. I've never felt that it is a problem. What is with these people? My feeling about these suggestions has always been that they have read about similar insecurities in C code run by the super-user, and are trying to get the teacher's attention by proposing something clever. Or is there really a problem? Is anyone in this forum aware of security issues with tempfile? Should I worry? Is the "random-tempfile" patch that the poster below suggested worth applying? --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Sun, 21 May 2000 19:34:43 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no> To: Guido van Rossum <guido@python.org> cc: patches@python.org Subject: Re: [Patches] Patch to make tempfile return random filenames On Sun, May 21, 2000 at 12:17:08PM -0700, Guido van Rossum wrote: > Hm, I don't like this very much. Random sequences have a small but > nonzero probability of generating the same number in rapid succession > -- probably one in a million or so. It would be very bad if one in a > million rums of a particular application crashed for this reason. > > A better way do prevent this kind of attack (if you care about it) is > to use mktemp.TemporaryFile(), which avoids this vulnerability in a > different way. > > (Also note the test for os.path.exists() so that an attacker would > have to use very precise timing to make this work.) 1. the path.exist part does not solve the problem. It causes a racing condition that is not very hard to get around, by having a program creating and deleting the file at maximum speed. It will have a 50% chance of breaking your program. 2. O_EXCL does not always work. E.g. it does not work over NFS - there are probably other broken implementations too. 3. Even if mktemp.TemporaryFile had been sufficient, providing mktemp in this dangerous way is not good. Many are likely to use it either not thinking about the problem at all, or assuming it's solved in the module. 4. The problems you describe can easily be overcome. I removed the counter and the file-exist check because I figgured they were no longer needed. I was wrong. Either a larger number should be used and/or counter and or file-exist check. Personally I would want the random part to bee large enough not have to worry about collisions either by chance, after a fork, or by deliberate attack. Do you want a new patch that adresses theese problems better? - -- Ragnar Kjørstad _______________________________________________ Patches mailing list Patches@python.org http://www.python.org/mailman/listinfo/patches ------- End of Forwarded Message
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4