shutil.copy and shutil.copy2 first copy a file content and afterwards
change permissions of a destination file. Unfortunately, the sequence isn't atomical and may lead to disclosure of matter of any file that is being duplicated.
            
Additionally, shutil.copyfile procedure seems to have a problem with symlinks that could result in the corruption of content of any file on filesystem (in favorable conditions).

Some functions from shutil module that depend on copy[2] (and thus copyfile) are vulnerable too.
For example, shutil.move is using copy2 when os.rename fails because of file transfer between filesystems.

I have attached listing from strace(1) system utility below that illustrates the disclosure problem.

# ls -l ./shutil_test
-r-------- 1 root root 10 06-18 11:42 shutil_test

# strace -- python -c "import shutil; shutil.move('./shutil_test', '/tmp')"
<many irrelevant lines>
open("./shutil_test", O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
open("/tmp/shutil_test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13e000
read(3, "blablabla\n", 16384)           = 10
read(3, "", 12288)                      = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13d000
read(3, "", 16384)                      = 0
write(4, "blablabla\n", 10)             = 10
close(4)                                = 0
munmap(0x7fd82e13d000, 4096)            = 0
close(3)                                = 0
munmap(0x7fd82e13e000, 4096)            = 0
stat("./shutil_test", {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
utimes("/tmp/shutil_test", {{1340012952, 0}, {1340012539, 0}}) = 0
chmod("/tmp/shutil_test", 0400)         = 0

Quick fix for the first issue could rely on os.umask but much more elegant and composite solution might use combination of os.open, os.fchmod and os.fdopen instead of open(dst, 'wb') in shutil.copyfile procedure which additionally rectifies the problem with symlink attack.
However, I am not sure that the last one is portable and won't mess with another code.
I have prepared *untested* patches for both propositions.

Best regards,
Radoslaw A. Zarzynski

It's not that simple as we currently use public functions for copying the files and the metadata. copyfile is explicitly _not_ supposed to copy any metadata so we can't patch it up to do so. Also that won't help for other stat & xattr data so this fix would be rather incomplete.

umask is ruled out too, because that isn't (if I'm not mistaken) thread safe thus wouldn't help against stat & xattr disclosures anyway.

Therefore we'll have to re-implement the whole metadata "stack" for copy and copy2 using fd-based functions. Taking into account #4489, I guess it's the best way (+ hoping someone implements safe versions for other platforms too).

The mode itself can also be copied pretty easily using a custom opener for open (os.open has a mode argument).

I doubt I will be able to do that till beta1 though. But I suppose we can commit this while in the betas?

That shouldn't be too complicated, but does Windows have fcomod() & Co?

Windows doesn't have fchmod(), but chmod() doesn't do much on it either:

“Although Windows supports chmod(), you can only set the file’s read-only flag with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding integer value). All other bits are ignored.”

(Windows has a sophisticated file permissions scheme, but you probably need to use native APIs to effect them)

Is this really only 3.4?  Since it is security-related, it seems like it should be at least considered for older versions as well.

(Note:  I am talking only about the disclosure issue; file corruption would ideally be fixed as far back as possible, though I would be somewhat sympathetic to a "nah, that ain't security, too late" argument.)

My current UI shows this as relevant to every release *except* 3.4 and 3.8.  If it is really 3.4 only, I think it should be closed -- anyone still using 3.4 *and* able to install from source is likely to be more upset by unexpected (and possibly silent) breakage of an existing process than new exploits of a 6 year old bug.  

If it really does apply to 3.5-3.7, then it would be good to do the same fix in all (and to match 3.8, which presumably is also affected, and simply wasn't available to check when the Versions were last set).

If, for some reason, the *right* fix on 3.8 (or at least 3.7 or 3.6) doesn't apply to earlier 3.x versions, I suggest closing it as won't-fix on those older versions.

That said, I'm probably the wrong person to verify which versions are affected, so consider this as only soft support for Release Manager to do so if this continues to languish.