shutil.copytree() uses shutil.copyfile() to copy files recursively.
shutil.copyfile() opens the source file for reading, and the destination
file for writing, followed by a call to shutil.copyfileobj().

If the file happens to be a named pipe rather than a normal file,
opening for read blocks the copying function, since the Unix OS needs a
writer process to attach to the same named pipe before the open-for-read
succeeds.

Rather than opening the file for reading, the correct action would
probably be to simply create a new named pipe with the same name at the
destination.
Looking at the Python2.3 code, the same type of problem seem to exist
for other non-normal file-types other than symlinks (eg device files,
sockets, and possibly a few others).

I am not sure if copyfile() should be trying to copy named pipes (or any
other special files for that matter). The best way is perhaps to check
and skip such files.

I can confirm this issue on python 2.5.
I think the priority should be set to critical, as this can lead to
denial of service attacks.

The open('fifo', 'rb') already blocks. One has to use os.fdopen with
O_NONBLOCK to prevent blocking.

fd=os.open('fifo', os.O_RDONLY | os.O_NONBLOCK)

and then use

stat.S_ISFIFO(os.fstat(fd).st_mode)

to check if this is a fifo.
Checking with os.stat before opening with open will result in a race
condition.

if the destination is a named pipe, it will also block (waiting for a
reader).

Note that the 'cp' user command in Linux blocks also. Although this is
*very* painful, you could argue that since the OS commands do the same
thing, it shouldn't be fixed.

I'm not sure the race condition possibility is important. Is
shutil.copytree() protected against such race conditions in the first place?

(I'd argue this bug is less about potential DOS attacks than the simple
unfriendliness of indefinitely blocking)

Here is a patch, introducing a new exception named SpecialFileError
which is raised when trying to copy a named pipe. Other kinds of special
file aren't checked for, but they could it we thought it's sensible to
do so.

I forgot the case where the /destination/ file is a named pipe. Here is
a new patch.

Committed in r72178, r72179. Thanks!