It seems like I’ve asked this before…but I can’t find it (I did try a search).
The default_dispvm setting in global configs is great, but for some reason it doesn’t carry through to named disposables. If you go to the settings for a named disposable and select the (default) setting, you get the Named Disposable’s own DVM template, even if something else is set globally; its as if named disposables simply override this setting.
I have a lot of named disposables, and I have to hand-set every single one of their disposables to the one I actually want. Then if I have to regenerate my intended default disposable, or its template, or THAT appVM’s template, I have to go through and hand set all the named disposables’ default disposables to something else…then undo that later once my rebuild is complete. Otherwise, I’d just have to change the global setting, then change it back.
This is a bit aggravating, and I can’t figure out why anyone would want to set a named template’s default disposable to its own DVM template, but even if there’s a logical reason, it seems like there ought to be a way to NOT do this that’s less tedious.
The special logic applies whenever a new unnamed disposable is spawned by any disposable, named or unnamed. Maybe it should be narrowed down to only the latter.
I remember being pleasantly surprised by this behaviour, after setting up some no-net, no-anything named disposable(s), as I hadn’t thought about what they would use as their dispvm. In my case, the default case was the most secure.
I think it is not bad as a behaviour, although the Principle of Least Surprise make me wonder if the term “default” is a bit overloaded.
I create a dvm specifically to serve as a thing to open documents and view them in isolation–and this “feature” does its best to ensure I won’t be able to actually USE it for this purpose without a lot of unnecessary pain–because my named disposables WON’T have this set as their default unless I specifically, one-by-one, set them to do so…never mind the fact that there’s a “global” setting that SHOULD be doing this.
I just had to write a script to step through all of my VMs, and change the default dvm for these qubes, because changing the global default does no good because I can’t USE it for this. It was that or spend fifteen minutes changing them all, one by one.
All so I could delete and rebuild the template of my default dispvm.
But I really don’t want it doing this for a numbered disposable either. If I am using a browser in one, download a file and want to view it, i CAN’T because it’s trying to go to its own template (which doesn’t have LibreOffice or even an image viewer installed). To say nothing of the fact that the policy file won’t allow it anyway, since the template isn’t listed there as an allowed recipient (and OBTW even if it did work, it would open ANOTHER browser disposable THAT HAS NETWORK ACCESS…which is the very problem Marmarek thought he was solving).
In other words, opening another copy of the VM that has network access to avoid network access, is worse than poinless.
In fact it’s even worse for numbered disposables, because unlike with a named disposable there’s absolutely NOTHING I can set to prevent this from happening, because until I start it there’s no qube that exists that I can do a qvm-prefs on.
I honestly can’t see how this makes any damned sense.
If you run qvm-open-in-vm @default your-file you should be able to select “Disposable VM (your document viewer disposable template)”. Unless there’s a custom deny policy causing it to be hidden?
However, I do see some sense to the logic of this being the default:
Disposables are often (always?) used to impose minimal, or decreased, privilege for some purpose, to confine the bad.
For named disposable, it is usually for a single, specific ,purpose. For both types, it is probably undesirable to give an increased privilege to anything opened in a disposable by another disposable.
Without some formal model of ~~levels of ~~privilege, the only way to guarantee “no greater privs” is to give “equal privs”.
OTOH, I feel your pain… and I haven’t really thought about it very deeply. My reaction was just because I rather liked that my “dirty” documents didn’t get given -by default - network access or anything extra than in their source qube.
…at least, that’s what I remembered, but now I’m having doubts about what actually gets inherited by disposables. I seem to recall a not-so-nice surprise, too, although it may have been that I hoped for the same behaviour for regular disposables though I do not recall what.
Anyway, the new PR causes some newly created disposables to be leaky by default. Current behaviour seems the only one for disp-of-a-disp that maintains compartmentalization in all cases.
I have to admit I have been a bit confused relating to this issue, and I apologize for the factually-wrong statements I have made. This is what I get for visiting this forum from a non-qubes machine!
Here, as near as I can tell, is the current behavior:
A disposable virtual machine template (which I abbreviate as “dvmt”) that fires up numbered disposables (disp1234), is where one sets the default disposable that will run in disp1234s launched from it. THIS defaults to whatever your systemwide (qubes-prefs default-dispvm) is set to and you get that if you select the default. (This is exactly what I want.) If I change the system default, and I selected “default” in the dvmt, the dvmt’s setting tracks that and I get the new system default.
A named disposable machine, on the other hand, must be hard-set to whatever the system default is, or it will pick its own dvmt as its default disposable template if you try to set it to use the system default. (This is NOT what I want.) This is true even if its dvmt has its default_dispvm set to “default.”
Aaahh, now I see and I can confirm this “bug”/behavior! It’s just that I rarely do anything in service qubes (that’s what I’m using named disposables exclusively for), and if I do, then it’s terminal mostly, and for that I’m using console in a qube and that fires dispVM which is internal/hidden and whose default dvm is default-mgmnt-dvm, so never paid attention actually…
For launching unnamed disposables, there’s currently no distinction between unnamed and named disposables in this regard. They behave identically. (My PR tried to introduce such a distinction, which turned out to be controversial.)
I think you might be mixing up two concepts: (1) Who’s launching an unnamed disposable - dom0 or any kind of qube, disposable or not, and if disposable: named or unnamed - and (2) what disposable template / dvmt it is instantiated from. A disposable template would typically not be launching unnamed disposables, ever.