[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r72178, r72179. Thanks!

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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

--
message_count: 8.0 -> 9.0
Added file: http://bugs.python.org/file13270/issue3002-2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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.

--
keywords: +patch
message_count: 7.0 -> 8.0
Added file: http://bugs.python.org/file13269/issue3002.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Antoine Pitrou]

Antoine Pitrou  added the comment:

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)

--
message_count: 6.0 -> 7.0
nosy: +pitrou
nosy_count: 4.0 -> 5.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[François Granade]

François Granade  added the comment:

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.

--
nosy: +farialima

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority: release blocker -> critical

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority: critical -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

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

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

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.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
priority:  -> critical
versions: +Python 3.0 -Python 2.3, Python 2.4

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

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.

--
nosy: +schmir
versions: +Python 2.4, Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[Raghuram Devarakonda]

Raghuram Devarakonda <[EMAIL PROTECTED]> added the comment:

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.

--
nosy: +draghuram

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3002] shutil.copyfile blocks indefinitely on named pipes

[albert hofkamp]

New submission from albert hofkamp <[EMAIL PROTECTED]>:

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).

--
components: Library (Lib)
messages: 67498
nosy: aioryi
severity: normal
status: open
title: shutil.copyfile blocks indefinitely on named pipes
type: behavior
versions: Python 2.3

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com