Github Issue #6128 - Remove --all flag from qvm-remove

General Discussion
1

Github Issue #6128 - Remove --all flag from qvm-remove

On on Oct 18, 2020 DemieMarie writes:

qvm-remove --all is essentially the QubesOS version of rm -rf --no-preserve-root /
qvm-remove --all should be an error.

Unman replies:

I’ve used this feature perhaps 10 times in the time I’ve been using Qubes - it’s absolutely not useless.
As to it’s being a footgun (sic), it does at least have a safety, since the user is prompted whether they wish to proceed. Of course, a user may respond Y to this, or indeed may call qvm-remove --all -f, but in that case they are getting exactly what they asked for, even if it is not what they wanted.
Since the option is clearly signposted, I doubt any user is going to use it by mistake, whereas rm -rf * is easily called by mistake in /

Demie Marie replies:

what have you used it for? From what I can tell, qvm-remove --all followed by a reboot leaves the system in an unrecoverable situation.

Unman replies:

I use this when travelling - since I salt my system it’s easy to travel
light, salt on arrival, and remove all later. But then I salt the
default qubes back. Never tried rebooting before doing this - since the templates aren’t
removed, why is the system unrecoverable? Or did you force removal of
some system wide requirement to really remove all qubes.

brendanhoar suggests:

the pattern is very similar to qvm-shutdown --all. I think that’s likely a potential cause of unintended data loss. Maybe instead of yes/no, require typing something like “yesdeleteallvms” or “ireallyknowwhatiamdoing”

Analysis

I am not sure about Unman’s claim that templates could not be removed via qvm-remove command. As far as I am aware, it is possible to remove the templates and sysvms via qvm-remove if they are turned off. Even removal of sys-net & sys-firewall could leave system in unrecoverable state.

Solution

brendanhoar suggestion sounds very logical and a good compromise. Showing a WARNING message if user types qvm-remove --all. And ask for their confirmation. I made it a little bit harder. User will have to type “IREALLYKNOWWHATIAMDOING” in capital letters. And Unman could still use the force by qvm-remove --all --force. So here is the patch:

patch 
diff --git a/qubesadmin/tools/qvm_remove.py b/qubesadmin/tools/qvm_remove.py
index 35ef09a..586813c 100644
--- a/qubesadmin/tools/qvm_remove.py
+++ b/qubesadmin/tools/qvm_remove.py
@@ -37,6 +37,15 @@ parser.add_argument("--force", "-f", action="store_true", dest="no_confirm",
 def main(args=None, app=None):  # pylint: disable=missing-docstring
     args = parser.parse_args(args, app=app)
     go_ahead = ""
+
+    if args.all_domains and not (args.no_confirm or args.exclude):
+        print("WARNING!!! Removing all domains may leave your system in an "
+              "unrecoverable state!")
+        go_ahead_remove_all = input("Are you certain? [N/IKNOWWHATIAMDOING]")
+        if not go_ahead_remove_all == "IKNOWWHATIAMDOING":
+            print("Remove cancelled.")
+            return 1
+
     if not args.no_confirm:
         print("This will completely remove the selected VM(s)...")
         for vm in args.domains:

I am going to submit the patch right away. Just want to know if there is anyone else who ever used qvm-run --all in their life.

2

Sorry never mind. Didnt read the --force part.

Original message:

Can we have something like --iknowwhatimdoing to still be able to do this automatically? I actually use this too to script automation setup - or better said to start from scratch.

1 Like
3

While we are at it, although that might be more complex. Something to remove VMs and do things like unassign PCI devices automatically (and whatever else might block a removal) would be nifty.

1 Like
4

of course it is possible. I am not sure what exactly you want to do. But I have been using customized versions of qubesadmin tools for a while. For example wildcard support for VM names. Here is the relevant forum thread:

1 Like