Five years ago, commit a9bd7120c4 changed the target directory of qfile-unpacker from /home/user/incoming to /home/user/QubesIncoming. Update the documentation accordingly.
Add API call to get default property value, without resetting it. And
without duplicating the logic behind it on the client side.
As discussed here:
https://github.com/QubesOS/qubes-manager/pull/44
Generally modifying storage volume/pool settings require removing and
creating the object again. This is not only API limitation, but most of
them really need the object to be recreated (for example storage pool
have most settings related to physical location of the data).
But some properties are safe to change. This applies to
`revisions_to_keep` (both storage pool and volume). Introduce
appropriate API methods for this. Put property name in API call name,
because argument is already used. And also because we don't plan to be
too flexible here - we may need to add one or two more mutable properties,
but definitely we don't want to allow any of them (as explained above).
The same applies to `persistent` option of device. There, in theory
detach+attach should be enough at all times, but in practice domain may
use the device (for example system being started from it -
QubesOS/qubes-issues#3055).
It is needed for VM clone operation: we have volume.Import, but not
volume.Export - at least not yet. And doing export+import would be very
inefficient, especially on smart storage pools (like LVM).
1. Drop separate admin.vm.microphone.* calls - lets use
admin.vm.device.mic.* for this. Yes, this means microphone cannot
be attached to multiple VMs at the same time (which is regression vs
Qubes 3.2). But this is a good thing from security point of view.
2. Drop admin.backup.Restore - use standard Admin API methods
(admin.vm.Create, admin.vm.volume.Import etc)
Cc: @kalkin
- devices can be attached with some options (like 'ro=True' for block
devices)
- clarify that backend domain and device ident is separated with '+'
(':' is not allowed in qrexec call argument)
- clarify how to attach devices "persistently"
Handling each rule separately makes sense on from qvm-firewall tool
point of view, but not from overall configuration integrity. If multiple
tools try to configure firewall simultaneously, doing it at individual
rules level can end very badly.
So, get/set the whole firewall at once. If some race condition happen
here, it will end up with one firewall rules set being overwritten by
the other one. But it will still be a consistent rules set.
