Rely on qrexec-client resolving QUBESRPC keyword, same as in case of VM
call. This will allow applying special treatment to such calls, like
calling qubes-rpc-multiplexer directly (avoiding shell), because we have
defined protocol what can be used here.
Using '$' is easy to misuse in shell scripts, shell commands etc. After
all this years, lets abandon this dangerous character and move to
something safer: '@'. The choice was made after reviewing specifications
of various shells on different operating systems and this is the
character that have no special meaning in none of them.
To preserve compatibility, automatically translate '$' to '@' when
loading policy files.
After the change of target keywords, apply transparen translation from
old names. This will avoid breaking calls from not updated VMs. Apply
this change only in stable branch.
Those parameters eventually may eventually be passed to a shell script
(at least /usr/lib/qubes/qubes-rpc-multiplexer). While it is possible to
properly escape shell special characters, lets do safer and less fragile
thing: forbid such characters entirely.
In case of target name, qrexec policy keywords are allowed, and after
recent change, those contains '@', so allow this char.
(cherry picked from commit cf28dad1943bd424b2ed23000cdcfd32d8e3190c)
This avoids duplicating service call parsing in multiple places. For
dom0 part it was in qrexec-policy tool.
Also, add execl() error handling.
(cherry picked from commit 32b0c659a1)
When policy specify 'target=' option, update 'vm' variable too (used to
start appropriate domain), not only 'target' variable (used to
make the actual call. Otherwise wrong domain is started (original one,
not the one overriden by target= option), and the call fails - since
the right domain is not running.
There was a second place with exactly the same bug. See
dad208a "qrexec: fix pending requests cleanup code" for details.
FixesQubesOS/qubes-issues#2699
(cherry picked from commit 8719e5d74c)
There was a logic error in pending requests cleanup code, causing
policy_pending_max being set to 0, even if there were more pending
requests. This effectively limited maximum pending requests to 1, after
some system uptime, because policy_pending_max set to 0 makes the code
looks only at the first pending request slot.
While at it, remove outdated FIXME comment, actually this bug is in the
code implementing this FIXME.
FixesQubesOS/qubes-issues#2699
Design documentation says:
'note string dom0 does not match the $anyvm pattern; all other names do'
This behaviour was broken, because 'is not' in python isn't the same as
string comparison. In theory this could result in some service
erroneously allowed to execute in dom0, but in practice such services are
not installed in dom0 at all, so the only impact was misleading error
message.
FixesQubesOS/qubes-issues#2031
Reported by @Jeeppler
qrexec-client -t/-T (and therefore, qvm-run --pass-io) only handled the
escape character, \033. Everything else, such as Unicode and obscure
control characters, was passed through from the VM to the dom0 terminal.
Instead, replace all bytes except for a benign subset of ASCII. That's
still enough to allow progress bars to be drawn (tested using
"wget --progress=bar:force" and "pv --force").
/usr/local resides in private.img, so it is possible to define per-appvm RPC
Also, with the upcoming 3.0 release support for old (R1) paths is
removed.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
This will allow to use some different shell/language for a service (for
example python).
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
When qrexec-agent crashes for any reason (for example
QubesOS/qubes-issues#1389), it will never connect back and qrexec-client
will wait forever. In worst case it may happen while holding qubes.xml
write lock (in case of DispVM startup) effectively locking the whole
system.
FixesQubesOS/qubes-issues#1636
Otherwise if the child process isn't reading its stdin at that time, it
would deadlock the whole qrexec connection (for example preventing
reading the data from the child, which may be a cause of that deadlock).
QubesOS/qubes-issues#1347
Do not reimplement manual VM state checking in qrexec-policy.
`qubes.xml` is loaded anyway, so just use QubesVM object to check if
domain is running.
FixesQubesOS/qubes-issues#1283
Make sure that all the data from local process is sent (including final
EOF), before handling its exit code - which would include terminating
qrexec-client process.
This will prevent passing an option instead of command (qvm-run) /
domain name (qrexec-policy). In both cases when VM tries to pass some
option it would fail because missing argument then - VM can not pass
additional arguments, so if one act as an option, one argument will be
missing).
This reverts commit 79abec9038.
The problem will not be applicable in new protocol, where vchan
connection is directly between VMs, so there is no longer two connected
qrexec-clients - always one end of data flow in qrexec-client is vchan,
which provide information about amount of data to read or buffer
space to write (lack of the later in case of pipes was a cause of the
original problem).
