readlink(2) does not write a terminating NUL, and the read side
will already place a NUL after whatever it receives.
While it seems odd that this would be buggy (ie, synlinks on
the ohter side would be pointing to the wrong filename, though
I guess if we're lucky and the stack had a 0 byte at the right
place, symlink(2) would do what was expected), my reading of
the code tells me this patch is right. Needs testing to double
check.
This avoids the possibility that incoming files may match
an existing file in /tmp (whether from the target VM, or a
third VM that's also sent a file for editing), as well as
possible file leaks between domains.
If we're being sent something without a zero byte, we
could happily read off the end of the buffer. Interestingly,
the write part was checking for the max bound.
That one would also send more data to the other VM that what we
intended: the start of the env var data (which in similar code
on my host includes the GPG agent socket path, XDG session cookie,
and more.
The other side expects a fixed size though, so pad with NULs.
Interestingly, the original code was not vulnerable as it was
callocing enough space.
This time it is for cups, which have socket-based and path-based
activators. When activator tires to start the service which is disabled
by condition file it enters infinite loop (as service wont start, but
will not report an error).
This reverts commit 047a7a0b23.
Actually some g-s-d plugins are helpful, for example notification of low
disk space. Also we've already disabled keyboard plugin.
read() syscall do not guarantee to read as much data as requested. This
is especially important when reading from pipe - remote end can produce
data slower than we are reading them. Use read_all() helper to always
get requested amount of data.
Assume that all the files of directory are in continuous block (which is
true in case of qvm-backup stream). This will allow to terminate before
getting to the file end - especially useful when only qubes.xml
requested.
