If the VM is powered off shortly after startup, it may happen that
qubes.SetMonitorLayout would start it again. Avoid this by using
autostart=False argument to run_service() function.
Note that there is a vm.is_running() check at the beginning of the
function already, but if it happens while the VM is cleaned up, it may
still report that it's running, but at the time of run_service() call it
is not.
This allows to run a service but do not cause a qube to be started it
isn't already running. This is especially useful for background /
internal calls designed to service a running target VM - if VM is not
running, those do not make sense to be called in the first place.
Specifically, this will allow qvm-start-gui to avoid re-starting a
domain while calling qubes.NotifyMonitorLayout, when a VM is shutdown
shortly after its startup.
Previous commit introduced protection against uncommon (potentially
malicious) compression filters. This breaks restoring backups made with
a custom compression filter. Add an option to override this check, by
naming compression filter to use explicitly.
Compression filter named in a backup header is executed in restore
environment (commonly dom0). While this field is properly authenticated,
there may be cases where backup archive comes from less
trusted source, like migrating from potentially compromised
system.
Modify backup header parsing code to add field specific validators.
Whitelist only know crypto, hmac and compression algorithms.
Based on a patch by Jean-Philippe Ouellet <jpo@vt.edu>
Reported-by: Jean-Philippe Ouellet <jpo@vt.edu>
* origin/pr/99:
devices: add missing docstring for _get_device_classes
devices: make iteration device classes compatible with Python2
tools/qvm-device: make PEP8 happy
tests/devices: add test for handling listing device classes
tests/devices: make PEP8 happy
devices: handle listing of available device classes
devices: make PEP8 happy
Add support for importing volume data with qvm-volume tool.
This could be also used to clear volume by issuing:
qvm-volume import --no-resize some-vm:private /dev/null
QubesOS/qubes-issues#5192
Reinstalling template is a recommended way to get it back to a clean
state after potential compromise. In that case it is essential to
discard any persistent storage of old template, as it could be used by
the attacker to re-compromise it after reinstall.
Do this similar as root volume is overridden - via volume import
function.
FixesQubesOS/qubes-issues#5192
Fix syntax workaround for python3.7 + python2.7. This code can't use
'yield from' to be still importable on python2.7, but asyncio.sleep() is
no longer iterable on python3.7. Workaround it by manually calling
coroutine.send(None) in a loop - ugly as hell, but works. I can't wait
until we could drop python2 support...
Addresses review comments, specifically:
* updates qvm-clone tests to handle ignore_errors option
* adds manpage reference to new --ignore-errors option
* trims line length in qvm-clone changes
All tests should now be passing, including the new qvm-clone
functionality.
The method will ensure the parameters are properly handled as actual
separate arguments, regardless of shell special characters in them.
For now implement this with shlex.quote, later dedicated qrexec service
could be used.
QubesOS/qubes-issues#4850
Retry connection on any OSError, instead of only few selected error
types. For example PermissionError may happen too (when socket is
created, but before it gets appropriate mode), which wasn't listed.
Specify compression explicitly in the backup profile, not only when
requested with --compress or --compress-filter.
This will allow to disable compression with --no-compress option, as the
default if no compression is specified in the profile is to use gzip.
FixesQubesOS/qubes-issues#4803
Since no output from VM is passed (and even if it would, it's redirected
to /dev/null), there is no need to switch output color.
This fixes the case when qvm-run is started in background - the color
change would affect further shell output.
FixesQubesOS/qubes-issues#4808
For various reasons, decryption may be slower than initial encryption
(different hardware, different system load etc). Do not fail the restore
operation if scrypt anticipate it will take considerably more time or
memory, than while creating the backup (where the scrypt parameters were
originally set).
Thanks to @jharveyb for the report and suggested solution.
FixesQubesOS/qubes-issues#4683