When rule does not specify forced target (`target=...`), generic
`$dispvm` wasn't resolved to specific Disposable VM (based on
`default_dispvm` property).
This way it will work independently from where qrexec-policy tool will
be called (in most cases - from a system service, as root).
This is also very similar architecture to what we'll need when moving to
GUI domain - there GUI part will also be separated from policy
evaluation logic.
QubesOS/qubes-issues#910
- drop qid usage - it isn't really needed, especially for to-be-created
DispVMs
- use "domains_info" dict as input, instead of loading qubes.xml
directly
- nicely format "Disposable VM" entries
- simplify whitelist/blacklist handling - since qrexecpolicy always
provide a list of allowed choices, use just that
Important note: there are two names concepts:
1. Display name - name of VM, or in case of to-be-created DispVMs - a
string "Disposable VM (name-of-base-vm)"
2. API name - as in qrexec policy - $dispvm:name-of-base-vm for new
DispVMs
Externally at API level (allowed targets list, return value), API name
is used, but internally VMListModeler._entries is still indexed with
display names. This is done for more efficient (and readable) GUI
handling - because most of the time it's searched for what user have
entered.
QubesOS/qubes-issues#910
Import unmodified implementation done by @boring-stuff.
Full history for reference is available in rpc-confirmation-window
branch.
QubesOS/qubes-issues#910
This socket (and commands) are not exposed to untrusted input, so no
need to extensive sanitization. Also, there is no need to provide a
stable API here, as those methods are used internally only.
QubesOS/qubes-issues#853
This is rewritten version of core-admin-linux/qrexec/qrexec-policy.
It's placed outside of `qubes` module on purpose - to avoid imporing it,
which require a lot of time.
QubesOS/qubes-issues#865QubesOS/qubes-issues#910
