As we all know, if you attempt to shut down sys-net (or whatever qube is fulfilling that role), you’re not allowed to do it because it’s the network vm of sys-firewall (or, again, whatever qube is fulfilling that role). A popup shows up to warn you of this. (In some cases you’re allowed to go ahead and do it anyway.)
A kill, of course is another story.
My question is, is this a mechanism we can customize and leverage off of? If I have a qube which has (for instance) mounted a block device, I might not want it to just shut down, I’d like to at least be warned.
So if dom0 is actually asking the qube “is it okay to shut you down”, I would like to know how to get the qube to answer that with something other than “sure, fine by me.” On the other hand, I can also imagine that in the specific case of network VMs, dom0 is actually looking to see who depends on whom and enforcing the restriction all by itself (in which case I see little hope of being able to add to the mechanism, unless that is controlled in some sort of configuration file somewhere).
dom0 does not ask the qube - it’s a check in /lib/python3.8/site-packages/qubes/vm/mix/net.py
Look at line 311-
@qubes.events.handler('domain-pre-shutdown')
def on_domain_pre_shutdown(self, event, force=False):
''' Checks before NetVM shutdown if any connected domains are running.
If `force` is `True` tries to detach network interfaces of connected
vms
''' # pylint: disable=unused-argument
connected_vms = [vm for vm in self.connected_vms if vm.is_running()]
if connected_vms and not force:
raise qubes.exc.QubesVMError(self,
'There are other VMs connected to this VM: {}'.format(
', '.join(vm.name for vm in connected_vms)))
Look in /lib/python3.8/site-packages/qubes/vm/qubesvm.py for the
domain-pre-shutdown event.
Of course. Create a new event handler, and raise an error - I’ve done
this with attached devices. You’ll need to do some introspection to
determine of a device is actually mounted, if that really is what you want.
Sounds like it’s entirely in dom0, but (contrary to my expectations) it’s still something I can work without having to recompile QubesOS itself.
This is good because I just half an hour ago burned myself by closing a split vera decryptor that had clients attached to volumes it had decrypted. Fortunately nothing got corrupted.
(A simple way to avoid this, in this particular case would be to not shut down if a thumbdrive is attached to that decryptor qube, since that’s where the volumes are stored.) In general, a client of such a service should refuse to shut down as long as it has a decrypted volume mounted, too. But as you said, that’s introspection I need to do, but first I need to play with this and see if I can get it to work at all. (Being set up in a language I don’t know doesn’t help; on the other hand it’s not an obscure one like some of the ones I run into around here, so duckduckgo university should get me far.)