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.
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.
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
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
Something like vm1 vm2 allow, user=foo would be 4 items,
and the user part would be ignored by the parser.
It might or might not be better to error out instead of
just warning, though...
