linux-utils/qrexec-lib/unpack.c:
Different compile errors will abort. Both different for fc20/21 but
based on same error below:
*
* FC21 ERROR: (but FC20 needs the code)
* unpack.c:31:0: error: "O_TMPFILE" redefined [-Werror]
* #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
* ^
* In file included from /usr/include/bits/fcntl.h:61:0,
* from /usr/include/fcntl.h:35,
* from unpack.c:4:
* /usr/include/bits/fcntl-linux.h:151:0: note: this is the location of the previous definition
* # define O_TMPFILE __O_TMPFILE / * Atomically create nameless file. * /
* ^
* cc1: all warnings being treated as errors
* <builtin>: recipe for target 'unpack.o' failed
*/
/* #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY) */
When file opened with O_TMPFILE but use_tmpfile==0, the file will not be
linked to the directory (the code at the end of process_one_file_reg).
Additionally it is waste of time trying using O_TMPFILE when it's
already known it shouldn't be.
Also use_tmpfile==0 can mean we don't have access to /proc
(set_procfs_fd wasn't called), so even if linking the file to its
directory would be attempted, it would fail. This is the case for
dom0-updates copy.
Otherwise source domain can modify (append) the file while the user
already is accessing it. While incoming files should be treated as
untrusted, this problem could allow file modification after the user
makes some sanity checks.
It can happen that we already cleared libvchan_fd pending state via
libvchan_wait, but data arrived later. This is especially true just
after connection, when client send unsolicited notification to server,
which can confuse it with some requested notification.
By passing an empty file with a declared negative size,
a hostile VM can decrease the total bytes counter, while
not have do supply a huge amount of data, thus disabing
the byte size check, and potentially filling the target
filesystem.
Also do not rely on unpack being called just once if we don't
have to and initialize counts.
Since we don't know directory size before populating with files,
we just accumulate the size on the second pass, but do not actually
check for the limit being reached. If there's any file after that,
that'll trip the check.
The byte limit would be hit if adding one byte to a buffer
that's half the limit, due to the temporary double copy.
Not sure if that's something that's worth changing.
