Opening more programs in running disposable Appvm?

[user00]

So if I have say, Firefox, open in a disposable qube and that is the only thing running in that Qube; how can I open a terminal in that Qube? I presume I need to do this with some commands from dom0 terminal?

[unman]

Note the name of the disposable qube from the title bar - then just
qvm-run <name> <command> from dom0

[427F11FD0FAA4B080123]

I presume I need to do this with some commands from dom0 terminal?

You can click on the Q icon in the system tray, select your Qube of interest, and click “Run Terminal”.

Also, in i3, if the window from this VM is in focus, Meta+Enter should open the terminal for you.

[deeplow]

A nice use-case for this is being able to open multiple documents on the same dispVM. However, there is not on-interface solution to this. Only through the terminal / through “run command in qube” as suggested.

This came up in the securedrop-workstation a while ago:

Investigate per-source dispVM

[Sven]

A nice use-case for this is being able to open multiple documents on
the same dispVM.

I do this all day long. This workflow [1] works not only for URLs but
also for files / documents.

However, there is not on-interface solution to this.

Basically you configure qubes.OpenInVM to always ask… that will
produce the dom0 dialog where you can choose the already existing
disposable qube as target.

That’s 100% pure GUI after it was setup once.

[1]

Qubes-Community/Contents/blob/master/docs/common-tasks/opening-urls-in-vms.md

[deeplow]

@Sven

Basically you configure qubes.OpenInVM to always ask… that will
produce the dom0 dialog where you can choose the already existing
disposable qube as target.

That’s 100% pure GUI after it was setup once.

Thanks a lot for the tip. Always learning!

Re-using dispVMs

In the section above we’ve seen how using the ‘ask’ RPC policy allowed us to start a (disp)VM once and use it for opening subsequent URLs (or files) to avoid having to wait insane amounts of time for dispVMs to start. However this comes at the price of a loss in compartmentalization. It is thus up to the user to carefully pick destination VMs and to manage the lifecycle of dispVMs, killing it/them when necessary when a clean state is required.

@sven the way you suggest is great already. However, I’m particularly afraid of the highlighted part. I haven’t yet played too much with the RPC policies. But before digging into that, I’d like to ask you if the following is possible: having a named dispVM that is the predefined for srcVM.

That way, when the user clicked on “open in VM” (on the file manager), it would be the default target, so the user would not have to “carefully pick”.

[Sven]

I’d like to ask you if the following is possible: having a named
dispVM that is the predefined for srcVM.

… you mean target – right?

That way, when the user clicked on “open in VM” (on the file
manager), it would be the default target, so the user would not have
to “carefully pick”.
$anyvm $dispvm ask,default_target=my_special_dvm

[deeplow]

@Sven

I’d like to ask you if the following is possible: having a named
dispVM that is the predefined for srcVM.

… you mean target – right?

Nope. I mean source VM. For example. I’d like the default dispVM to be a named one, so that it always opens attachments on that same one, without me needing to select a target (named) dispVM.

[QubicRoot]

Hmmm… Perhaps we need to be a little clearer on the definitions? Is this correct?

• srcVM: Part 1: The qube that contains the attachment/document to be opened (edited/viewed).

• srcVM: Part 2: Also in its settings contains the Default DisposableVM Template.

• Default DisposableVM Template: The template qube to use for the created dispVM (duh! ).

• dispVM: The qube created on-the-fly. Also the targetVM.

@deeplow : If I understand you correctly, you would like an enhancement to change “Default DisposableVM Template” to “Default DisposableVM”, which could be either a Named dispVM or a DisposableVM Template. In the former case the Named dispVM would be (re-)used; in the latter case a new dispNNNN would be created each time, as now.

While only DisposableVM Templates are in the drop-down list in the Qubes Manager, interestingly qvm-prefs allows specifying a Named dispVM - but unfortunately it doesn’t take and actually resets the Default DisposableVM Template to None, without displaying any error - likely a bug?

@Sven : He may be asking if a set of entries is possible like:

vm1 $dispvm default_target=nameddispvm1forvm1
vm2 $dispvm default_target=nameddispvm2forvm2
etc…

Or I may just be confused!

[deeplow]

I’m afraid my question has steered the thread into another (yet interesting direction). But the original point seems to have been addressed and this goes in a very similar direction.

@QubicRoot

@deeplow : If I understand you correctly, you would like an enhancement to change “Default DisposableVM Template” to “Default DisposableVM”, which could be either a Named dispVM or a DisposableVM Template. In the former case the Named dispVM would be (re-)used; in the latter case a new dispNNNN would be created each time, as now.

Played around with it a bit and now I know what’s I’d like. I’d like to be able to set a named dispVM as the default dispVM for the srcVM such that whenever one clicks open in dispVM it would only boot one dispVM (the named one) and subsequent open in dispVM would open in the same one. This would make the workflow equivalent the one detailed by @Sven but without the need for the RPC dialogue for selecting the default target qube.

Hopefully I’m explaining myself correctly.

Basically my conclusion was that it is not possible because a named dispVM is of type DispVM and we can only select as Default disposableVM template an AppVM marked as DisposableVM template. Kinda confusing…

[Sven]

This would make the workflow equivalent the one detailed by @Sven but
without the need for the RPC dialogue for selecting the default
target qube.

Well, if you set the policy to “ask,target=my_named_dispvm” then the
dialog will come up but your named dispvm is preselected. So all you
need to do it hit the [OK] button. …that’s not quite what you wanted
but pretty close.

[deeplow]

Yup. I think as close as we’ll get for now. Thanks again for the tip.

[QubicRoot]

Actually,

srcVM $dispvm allow,target=targetVM

seems to eliminate the prompt…

Of course, you’d need such a line for each srcVM…

[unman]

The way I use this is to set named disposableVMs with the
qubes-shutdown-idle service configured for a short shutdown (2 mins I
think)
I use mailcaps and mimeinfo to set opening most files in a disposableVM,
and alias “open” to “qvm-open-in-dvm”.
Because all the heavy lifting is done in /etc/qubes-rpc/policy/qubes.OpenInVM
I have keyboard shortcuts to set/unset the default allow rules. That gives
me the flexibility of changing from “open files in separate disposableVM”
to “open files in the same disposableVM”.
You should be able to set this up yourself with minimal effort: if you
need help shout out.

[deeplow]

@QubicRoot

srcVM $dispvm allow,target=targetVM

seems to eliminate the prompt…

This is it. Thanks!!

@unman

The way I use this is to set named disposableVMs with the qubes-shutdown-idle service configured for a short shutdown (2 mins I
think)
I use mailcaps and mimeinfo to set opening most files in a disposableVM, and alias “open” to “qvm-open-in-dvm”.

Yes, I was already thinking of doing exactly the same.

@unman

Because all the heavy lifting is done in /etc/qubes-rpc/policy/qubes.OpenInVM

This makes me think about the possibility of dynamic RPC policies. Basically /etc/qubes-rpc/policy/qubes.OpenInVM could be an executable file who’s output would be the the actual policy. But this is probably a topic on its own.

@unman

I have keyboard shortcuts to set/unset the default allow rules. That gives me the flexibility of changing from “open files in separate disposableVM” to “open files in the same disposableVM”.
You should be able to set this up yourself with minimal effort: if you need help shout out.

Thank you. If I need, I’ll ping you then.