tarfile.py: _FileInFile():

(near line 687)

b = self.fileobj.read(length)
if len(b) != length:
    raise ReadError("unexpected end of data")

every read() API does not guarantee that it will read `length` bytes. So, if fileobj reads less than requestedm that is not an error (!)

In my case it was a pipe...

The same in tarfile.copyfileobj()

Can you give a demonstration script? I don’t see how this could be triggered. If you use a tarfile mode like "r|", it internally uses a _Stream object which has a loop to do exact reads: <https://hg.python.org/cpython/annotate/v3.5.1/Lib/tarfile.py#l567>.

well, I don't use "r|" (but will, thanks for suggestion)

In any case, assuming that read() returns exact length is wrong. There is .readexactly() (f.e. in asyncio I mean). Or, one should use simple loop to call .read() multiple times.

Reading from plain file does not guarantee, that read() syscall will return requested count of bytes even when these bytes are available.

On the other hand, you cannot use a pipe with mode="r" because that mode does seeking; that is why I asked for more details on what you are doing:

$ cat | python3 -c 'import tarfile, sys; tarfile.open(fileobj=sys.stdin.buffer, mode="r")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/tarfile.py", line 1580, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python3.5/tarfile.py", line 1610, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.5/tarfile.py", line 1467, in __init__
    self.offset = self.fileobj.tell()
OSError: [Errno 29] Illegal seek

Python 3 has the io.RawIOBase class which models the low level read() system call and does partial reads, and the io.BufferedIOBase class whose read() method guarantees an exact read. You can often wrap a raw object with BufferedReader to easily convert to the buffered kind.

Well, there are  more than one workarounds for that.

man read:
===============
If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read.
=====================

So, this is a way how to make "exploit" for this bug.

Please give us some example test code that shows us what goes wrong exactly.

Can not reproduce in Linux. Will reopen if reproduced on MacOS X or BSD.

#!/usr/bin/python3.5

import os
import signal


p = os.getpid()

if os.fork() == 0:
    while True:
        try:
            os.kill(p, signal.SIGCHLD)
        except (ProcessLookupError, KeyboardInterrupt):
            break
    os._exit(0)

qwe = open('qwe.dat', 'w+b')
qwe.seek(2*1024*1024*1024*1024)
qwe.write(b'0')
qwe.flush()
qwe.seek(0)
while True:
    d = qwe.read(65536 * 32)
    if len(d) != 65536 * 32:
        raise Exception('!')

http://stackoverflow.com/questions/1964806/short-read-from-filesystem-when-can-it-happen

Disk-based filesystems generally use uninterruptible reads, which means that the read operation generally cannot be interrupted by a signal. Network-based filesystems sometimes use interruptible reads, which can return partial data or no data. (In the case of NFS this is configurable using the intr mount option.) They sometimes also implement timeouts.

> can return partial data

Seems reading tar-file from NFS-filesystem may trigger that bug.