[Secure-testing-team] Bug#746467: pixz creates new file with default permissions and does not preserve permissions

[Michael Tokarev]

Package: pixz
Version: 1.0.2-2
Severity: important
Tags: security upstream


When pixz creates a file for the result of (de)compression, it uses
default umask, so file gets created with, say, 0644 permissions.
Even if the original file we're about to (de)compress has stricter
permissions.

This way, the data can be read by others during whole (de)compression
process, which, depending on the size of the input, can be quite
slow/long.

 $ ls -l data
 -rw-r----- 1 mjt mjt  8589942784 Apr 30 13:50 data
 $ pixz data &
 $ ls -l data.xz
 -rw-r--r-- 1 mjt mjt   135106560 Apr 30 13:52 data.xz

It is even more than this: the permissions are never restored even
after the process is completed.  The final data.xz has the same
0644 permissions as the temp file:

 $ wait; ls -l data.xz
 -rw-r--r-- 1 mjt mjt   725922432 Apr 30 13:55 data.xz

So the file stays with wide-open permissions, unlike the original.

Other compressors - gzip, xz, etc - tries to preserve the permissions,
and tries to keep the new/temp file (during compression) unreadable.
That's why user does not expect the new file created by pixz to have
wider permissions than its original.

(It looks like pixz does not preserve any attributes, including the
date, and it also looks like it modifies mtime of the _source_ file
too).