1) Instead of a set of predefined commands, we send MSG_AGENT_TO_SERVER_TRIGGER_CONNECT_EXISTING msg with a parameter (e.g. "org.qubes-os.vm.Filecopy")
defining required action
2) qrexec_daemon just forks qrexec_policy, that will take care of actually
allowing and executing required action
3) after MSG_AGENT_TO_SERVER_TRIGGER_CONNECT_EXISTING, qrexec_agent does not
execute a command - it justs uses already established file descriptors to
send data to/from. Thus, there is no need to use ~/.xxxxxspool - a command line
tool can have direct access to remote fds.
After yum transaction (install/upgrade/remove),
yum-plugin-post-transaction-actions will execute script which trigger
qvm-sync-appmenus in dom0 (through qrexec).
THIS INTRODUCE NEW PREDEFINED COMMAND IN QREXEC
In case a child of qrexec_daemon has exited and there is still data in its
stdout pipe, we need to flush it to the peer. Previously, the case when the
peer is blocked was not handled; it is now. The bug impact was premature EOF.
Processes in AppVM can ask qrexec-agent to send a
MSG_AGENT_TO_SERVER_TRIGGER_EXEC message to qrexec-daemon.
The latter will execute predefined program. It is useful for
the purpose of file copy; the predefined program will create
a connected qfile-daemon<->qfile-agent pair.
