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). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org