* qubesos/pr/34:
qfile-daemon-dvm: Implement LAUNCH and FINISH actions
qfile-daemon-dvm: Call static method by class name
qfile-daemon-dvm: Move dispVM killing into cleanup function
* qubesos/pr/33:
And some more quoting to satisfy #1672
Quoting all `cat`s as proposed in #1672
Modifying support cpio as proposed in #1672
Quoting the destination as proposed in #1672
If the action is LAUNCH instead of qubes.SomeService, then just start
the dispVM, write (only) its name to stdout, and quit.
If the action is FINISH, then kill and remove the named dispVM.
sfdisk options and input format differs between versions (dropped MB
units support), so instead of supporting all the combinations,
simply paste its result verbatim.
This is very easy if the file/device is in dom0, so do it to avoid
cryptic startup error (`libvirtError: internal error: libxenlight failed
to create domain`).
FixesQubesOS/qubes-issues#1619
dnf doesn't want to replace packages without --allowerasing (it is
needed to have correct kernel-devel package version). Additionally
really make sure the right version is installed and force u2mfn module
compilation.
There are problems with using sudo in early system startup
(systemd-logind not running yet, pam_systemd timeouts). Since we don't
need full session here, runuser is good enough (even better: faster).
On VM start, old qubesdb-daemon is terminated (if still running). In
practice it happen only at VM startart (shutdown and quickly start
again). But in that case, if the VM was started by root, such operation
would fail.
So when VM is started by root, make sure that qubesdb-daemon will be
running as normal user (the first user in group 'qubes' - there should
be only one).
FixesQubesOS/qubes-issues#1745
Enable e820_host option for VMs with PCI devices (to allow VM kernel to
deal with address space conflicts). But add a property to allow
disabling it.
FixesQubesOS/qubes-issues#2019
Make sure that even compromised frontend will be cut of (possibly
sensitive - like a webcam) device. On the other hand, if backend domain
is already compromised, it may already compromise frontend domain too,
so none of them would be better to call detach to.
QubesOS/qubes-issues#531
qrexec-daemon will start new processes for called services, which
include starting new DispVM, starting other required VMs (like backend
GPG VM). Having those processes as root leads to many permissions
problems, like the one linked below. So when VM is started by root, make
sure that qrexec-daemon will be running as normal user (the first user
in group 'qubes' - there should be only one).
QubesOS/qubes-issues#1768
