qubes-issues
qubes-issues copied to clipboard
QubesOS
Allow disposable qubes to be based directly on regular templates
The problem you're addressing (if any) Today a user must create a "Disposable Template" from an App VM. It is well understood why a user may desire that, but it feels odd to be forcing it.
Describe the solution you'd like Allow users to create Templates that are only to be used to spawn Disposable qubes from.
Where is the value to a user, and who might that user be?
- Users new to Qubes OS and learning its ecosystem
- It feels a bit silly to have to create at least one Template and one App Qube, to be able to have a Disposable Qube. Again, for the use-case where a user would desire having a Disposable Qube spawned from an App Qube for unusually sensitive things, it's awesome that this capability exists! It's just breaks an intuitive mental-model of how Qubes works, to shoehorn today's dependency on an App VM intermediary as a requirement.
Describe alternatives you've considered Nope
Additional context From a private conversation with @marmarek:
"One corner case (not a blocker for the idea) is what to do about template's private disk. Currently template's private disk is not share with anything based on it. On the other hand, DispVM does get snapshot of its template private disk (which is that intermediate app qube right now). If we're going to remove that intermediate qube, we need to decide: should DispVM get always clean private disk in this case, or should template's private disk be no longer that private?"
Relevant documentation you've consulted Nope
Related, non-duplicate issues Nope
It isnt necessary to "create at least one Template and one App Qube, to be able to have a Disposable Qube" - Qubes does this for you.
If this were to be implemented, then it would complicate the mental-model of how Disposable qubes work, because there would be those that are based on templates, and those based on qubes.
@unman The goal for this issue is to make the entire ecosystem of how qubes work within Qubes OS, easier to understand and more straightforward. To better inform the total mental-model of how Qubes works—without zeroing-in on one specific type of qube, to the possible exclusion of smooth comprehension of the broader system. Likewise, to make the persistence properties of app-qubes-as-templates an option, and not a forced attribute.
As a user new to Qubes, it also feels incredibly strange that a qube serving in the functional role of a disposable template must be an app qube, by type. The persistence properties of an app qube functioning in the role of a disposable template, is great—but it should be optional. Why is it forced?
I don't want to muddle any mental models. Quite the opposite. But, if I don't desire the filesystem persistence property of an app qube, I should be able to base my Disposable Qubes off a proper Template.
The need for a Disposable Template (being App qube) in between is only to customize files in default user home dir for Disposable qube, while not adding yet another full template that needs to be updated uses disk space etc. While architecturally it correct thing to do, UX-wise it is confusing - why for this particular role a template is app qube? And in fact, unless the user want to customize something in the disposable qube, there is no really need for this intermediate object.
So, adding an option to TemplateVM (type) being a template (role) for a DisposableVM simplifies the (common) picture. The other option (with "disposable template" in between) will remain there, for those who do want customized disposablevm - but that is part of "advanced configuration" that can be expected to require a bit more knowledge, compared to simple usage of "get me a DisposableVM with Debian/Fedora/Whonix/whatever".
On Fri, Jul 02, 2021 at 05:16:39AM -0700, Marek Marczykowski-Górecki wrote:
The need for a Disposable Template (being App qube) in between is only to customize files in default user home dir for Disposable qube, while not adding yet another full template that needs to be updated uses disk space etc. While architecturally it correct thing to do, UX-wise it is confusing - why for this particular role a template is app qube? And in fact, unless the user want to customize something in the disposable qube, there is no really need for this intermediate object.
So, adding an option to TemplateVM (type) being a template (role) for a DisposableVM simplifies the (common) picture. The other option (with "disposable template" in between) will remain there, for those who do want customized disposablevm - but that is part of "advanced configuration" that can be expected to require a bit more knowledge, compared to simple usage of "get me a DisposableVM with Debian/Fedora/Whonix/whatever".
I think we should aim to have the UX mirror the architecture in this case.
In my experience no one finds this confusing, and it makes it easier to instil a model which allows for future extension. But I acknowledge that that is mainly for people who do want the disposable template to be somewhat customised.
Looking back at the mailing list and forum, I see that this issue does come up. I would rate it as "intermediate" rather than "advanced" use. Even simple examples, like "I want the default disposableVM for this qube to use the Qubes documentation as default web page".
Simplifying the picture in this case, makes it much more difficult to create the model required to make even slightly more than minimal use of disposableVMs. That's why I don't like it.
N.B. That "simple usage" is already what I would call intermediate use. Simple use is "Here's a disposableVM Qubes has made for you." There are many users content with that.
I would appreciate if a template's /rw aka 'home' would be applied to a brand new qube based of that template. Currently I work around that by having a 'setup_qube' bash script I run after creating every new qube to setup the 'home' directory the way I want.
But that's in the context of normal templates and qubes and should probably be it's own issue.
What @ninavizz talks about can be entirely solved in the UI without touching the way Qubes OS works:
In the "Create new qube" dialog one could add "Disposable qube based on a template" as a type. The user can then choose a template (e.g. Fedora) and give a name. As a result the UI then creates an AppVM with that name, sets template_for_dispvm to true and the appmenus-dispvm feature.
The new user who just wanted a disposable qube got it. The intermediate user who wants to customize can do so in the qube that was just created. As a cherry on top we could have the UI and the CLI show "DispTemplateVM" instead of "AppVM" when the template_for_dispvm is true.
This way very little code has to change. Everybody who already has a mental model for how it works will simply see that "AppVM with template_for_dispvm = true" is now called "DispTemplateVM", while the new user as a straight and intuitive path to create the disposable qube template with nothing in the UI/UX that would confuse them. Once they want to customize the "DispTemplateVM" is the natural place to look.
I would appreciate if a template's /rw aka 'home' would be applied to a brand new qube based of that template. Currently I work around that by having a 'setup_qube' bash script I run after creating every new qube to setup the 'home' directory the way I want.
The canonical place for initial home directory content in Linux (that works in Qubes too) is /etc/skel. See also https://www.qubes-os.org/doc/templates/#inheritance-and-persistence
In the "Create new qube" dialog one could add "Disposable qube based on a template" as a type. The user can then choose a template (e.g. Fedora) and give a name. As a result the UI then creates an AppVM with that name, sets template_for_dispvm to true and the appmenus-dispvm feature.
Indeed this is a good idea too. It's still a bit more complex when it comes to manage it (especially when switching to another template - like fedora-N to fedora-N+1), but maybe that could also be solved at UI level.
On 7/2/21 4:44 PM, Marek Marczykowski-Górecki wrote:
The canonical place for initial home directory content in Linux (that works in Qubes too) is
/etc/skel. See also https://www.qubes-os.org/doc/templates/#inheritance-and-persistence
Thank you!
-- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7
I was about to start an issue about the inability to create a new disposable qube based on the debian-11 or other templates as they don't appear in the drop down list but after reading the thread here I understand the reason why being I have no debian based appVMs. Also all the issues here are regarding R4.1 (both rc1 and rc2).
I have to agree that the way disposable templates are handled currently in the UI is a bit confusing.
A standard install creates default DVMs based on whonix-ws and fedora as well as a default-mgmt-dvm. (I assume it makes a debian one if debian is selected as the default during initial install instead of fedora but I haven't tried it yet.)
The fedora and whonix-ws DVMs both list the main templates as the template they're based on and not any appVM.
In addition, every full Template has the Advanced >> Disposable template checkbox unchecked and the option cannot be checked in any full template (Invalid property 'template_for_dispvms').
However, using the UI to manually create a new DVM based on another template to mirror these is impossible because as soon as DisposableVM is selected in the drop down menu, all full template VMs are removed from the list. Only the fedora-dvm and whonix-ws-dvm qubes are shown.
The drop down list is another element of confusion as both the fedora and whonix-ws DVMs have the Disposable template checkbox checked (makes sense) but the default-mgmt-dvm also has the checkbox checked while it is not displayed in the drop down list. I'm sure there's a good reason why, but it's not obvious why from the UI.
Another issue is that the default system created DVMs actually list all the full templates in their settings menu and can be changed to any existing template. This allows the user to at least clone one of the default DVMs and then change to another template without the appVM creation or checking the Disposable template checkbox anywhere.
The differences between the default system created DVMs and manually created DVMs is the main source of confusion for me at least.
