New Paradigm: ability to set RW attribute of qube disks (enhanced disposable qubes)

[QUser534]

How to file a helpful issue

The problem you're addressing (if any)

Current implementation of "Disposable VMs" are a bit clunky in any use cases. For example, look at a disposable network VM. The current paradigm is to basically have two VMs: Disposable Template (RW) and then the Disposabe AppVM (RO).

This creates a lot of complications separating teh RW / RO by different VMs. It is non-intuitive and in the case of a network VM makes it very hard to do the very essential task of saving the WIFI password for connections. For example, it might require juggling the network hardware between both VMs anytime the Writeable VM needed to be used to create a permanent change (or else even more complex config hacks on the writeable VM).

The solution you'd like

The RW (read-write) / RO (read-only) status of a VM should not be divided on templates / vms, etc. It should simply be a configuration option that ANY VM can have at any time. This really expands the use cases of the special qubes setup.

Each qubes standard mounted disk should have 4 options in the qubes config under a "disks" tab or under "advanced":

1. No persistence (RO)
2. Always persist (RW)
3. RW next boot; RO thereafter
4. RO next boot; RW thereafter

#1 and #2 are basically the current paradigm but without any way for the user to change the values. Naturally, the System disk of an AppVM is not modifiable. however, the Private Storage disk should be. Currently it is always #2 in the case of a normal AppVM without any way to make it Non-persistent if required at a later date.

I understand that #3 / #4 may be controversial, but at a minumum I think #1/#2 would be useful to support. An AppVM private storage should be possible to set to Read-Only at any time.

Old Use Case Improvements: Going back to the prior example of a network disposable VM we now have one less VM (no need for a disposable template vm) saving random junk that accumulates in our menus. When we want something to be saved to disk we simply intuitively start up the VM with write mode set to (Persist Next Boot). Save our wifi config and done. Easy peasy!

New never imagined use cases: The current disposable template paradigm is very clunky which eliminates a lot of use cases. Many times I have a normal VM that has a bunch of data and software on it. I get the idea that I want to do some tests on it but I do NOT want any of the tests to be permanent. Under the current paradigm there is NO way to do this without making clones, rolling back lvm thin polls, etc. Basically clunky as heck!

With the new paradigm it is all simple. Just go into the Qubes Config, set the Private Storage mounted disk to Option 4 (RO next boot; RW thereafter). Bam! Very easy. Qubes starts up, I make changes, shut it down nothing persists, restart it and it functions as it did before.

The new paradigm NEVER reduces security. For example, it will not enable a user to make the system storage of an AppVM writeable or of a disposable VM, etc. It basically just enables the making of what is currently RW changed to RO either permanently (until changed) or for one time (where it automatically changes back after the next VM boot)

The value to a user, and who that user might be

1. Easier to configure disposable qubes paradigm

2. Better security as it enables running tests and trying things in an environment where nothing can persist. With the current hard to manage methods to work with RO qube states it discourages the use of RO qubes.

Current paradigm is clonky with many use cases (such as the given networking use case). This is more granular and less wonky alternative to expose the RO / RW of the available disks.

[asharp]

FYI: If you open a disposable qube using qube manager it opens in non disposable mode which lets you update the template. So you don't generally need two qubes.

[logoerthiner1]

FYI: If you open a disposable qube using qube manager it opens in non disposable mode which lets you update the template. So you don't generally need two qubes.

This feature is poorly documented as far as I know, and this is commonly believed to be a VM who is RO in most of the time and RW occasionally, rather than the converse. Sometimes one may want to make the VM storage readonly temporarily without converting the VM into a dispVM permanently.

Alternatively (may be off the topic), VM snapshot functionality may be preferred. qvm-volume may already implemented such functionality however it should be different when it has a GUI interface that visualize how many volume snapshots a VM has.