[Patches] [ python-Patches-589982 ] tempfile.py rewrite

[noreply@sourceforge.net]

Patches item #589982, was opened at 2002-08-02 02:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=589982&group_id=5470

>Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zack Weinberg (zackw)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempfile.py rewrite

Initial Comment:
This rewrite closes a number of security-relevant races
in tempfile.py; makes temporary filenames much harder
to guess; provides secure interfaces that can be used
to close similar races elsewhere; and makes it possible
to control the prefix and directory of each temporary
created, individually.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 12:48

Message:
Logged In: YES 
user_id=6380

I like the idea of fixing security holes.

This patch is *humungous*. Even just the doc changes and the
changes to tempfile.py itself are massive and require very
careful reading to review all the consequences.

Zack, can you try to interest someone with more time than me
in reviewing this patch?

What's the point of renaming all imports with a leading
underscore? I thought __all__ took care of that.

----------------------------------------------------------------------

Comment By: Zack Weinberg (zackw)
Date: 2002-08-03 02:53

Message:
Logged In: YES 
user_id=580015

I've revised the patch; ignore the old one.  This version
includes a vastly expanded test_tempfile.py which hits every
line that I know how to test.  The omissions are marked -
it's mostly non-Unix issues.

Also, I went through the entire CVS repository and replaced
all uses of tempfile.mktemp with
mkstemp/mkdtemp/NamedTemporaryFile,
as appropriate.  The sole exception is Lib/os.py, which is
addressed by patch #590294.

The sole functional change to tempfile.py itself, from the
previous, is to throw os.O_NOFOLLOW into the open flags. 
This closes yet another hole - on some systems, without this
flag, open(file, O_CREAT|O_EXCL) will follow a symbolic link
that points to a nonexistent file, and create the link
target.  (This has no effect on a symlink in the directory
components of the pathname - if the sysadmin has symlinked
/tmp to /hugedisk/scratch, that still works.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-02 10:45

Message:
Logged In: YES 
user_id=6380

This needs some serious review!

Volunteers???

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=589982&group_id=5470