When qfile-unpacker's child encountered an error, it would display an
error message and exit(1), but the parent didn't inspect its status and
exited successfully.
That was unfortunate for qvm-move-to-vm: Even if the destination VM e.g.
didn't have enough free disk space, the RPC call would claim to succeed
anyway, so the file would be deleted from the source VM.
/proc is needed to link files opened with O_TMPFILE to the filesystem.
If not available, fallback to using permissions to block file access,
instead of failing the whole file copy.
Otherwise, when the user moves directory, which is still in transfer,
somewhere else, it could allow malicious source domain to escape chroot
and place a file in arbitrary location.
It looks like bind mount is just enough - simple rename fails with
EXDEV, so tools are forced to perform copy+delete, which is enough to
keep unpacker process away from new file location.
One inconvenient detail is that we must clean the mount after transfer
finishes, so root perms cannot be dropped completely. We keep separate
process for only that reason.
