Instead of assuming process termination (because of write returned EPIPE), just
do not write to the process pipe, but still process the data in opposite
direction until EOF received.
When qrexec_client cannot write to its stdout, this doesn't necessary mean that
there is no data in opposite direction.
Simple example is RPC service: when process in destination VM closes its stdin,
it can still send some data to triggering VM.
This will allow to pass quoted arguments and some variable expansion. Basically
one-line shell command service can be embeded in the configuration.
In previus version use of "command path with spaces" whould result in try to
execute '"command' with arguments 'path', 'with' and 'spaces"'.
Most qrexec services doesn't use remote domain name, as policy is enforced
earlier. So pass it in way that will allow use of generic command as qrexec
service.
Previously dom0 had to know full path of qubes_rpc_multiplexer in VM, which can
differ between VMs (eg totally different on Windows). This commit enables dom0
to magic keyword instead of full path.
There are two problems with qvm-run -a:
1) even with -q flag, it spits to stdout (actually, "xl create" does it), and
this garbage is received by rpc client
2) even with -q flag, it steals input (actually, "qrexec ... wait for session")
These two can be manually fixed (by passing /dev/null appropriately); hovewer,
this is prone to disaster if qvm-run is enhanced/broken later.
We could do
if is_domain_running() ; then
run qrexec client
else
qvm-run -a domain true </dev/null >/dev/null
run qrexec client
fi
which looks safer; but is_domain_running() is a bit expensive even in "running"
case - we need to xl_context.list_domains anyway.
Gotta decide on one of these.
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.
