On 05/02/2018 09:25 PM, Ivan Mitev wrote: > > On 05/02/2018 06:29 PM, Marek Marczykowski-Górecki wrote: >> On Wed, May 02, 2018 at 05:22:55PM +0300, Ivan Mitev wrote: >>> Hi, >> >>> I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could be >>> used for more than one time, until the service call ends (eg. the >>> browser is closed by the user). The idea is to save resources/time and >>> allow several consecutive links to be opened in the *same* dispVM until >>> the user decides to scrap the VM by closing its browser. >>> It's of course less secure than using a dispVM for a single usage, but >>> it's much better than always using the same browser in an AppVM like I >>> do because a/ I usually don't have enough RAM to have several dispVMs >>> opened, b/ I'm usually in a hurry and don't want to wait for a dispVM to >>> pop up, c/ dispVMs don't have bookmark management. >> >>> But for that to work I need to set the dispVM's name (eg. >>> 'dispBrowsing') rather than the randomly generated "disp[0-9]+" string. >> >> You can start a normal DispVM and copy&paste links there. This is what I >> do - a habit from times where no other option was available. > > Yes I know, but I don't find it very convenient. The idea here would be > to have a non-networked AppVM with a bookmark manager (and maybe > password manager too) and use it to open links in a given dispVM; this > can be streamlined almost transparently without needing any copy/paste > between VMs by (re)configuring the mimetype scheme handler ([1] [2]). > > >>> `qvm-run` doesn't provide that functionality but it seems achievable >>> with qubes's python API. I had a look at some tests in >>> python/site-packages/qubes/... where dispVM names were hardcoded (eg. >>> 'disp42' or 'disp123') but before spending too much time trying to >>> understand those, I thought I'd ask here (+, the question seemed to be >>> too in-depth for the qubes-users ML) >> >>> It's important to retain the "shutdown/destroy when service call ends" >>> functionality; >> >> This seems contradicting what you want to achieve. If the VM should be >> destroyed after the call ends, it wont be there after opening one link. >> I think you've meant "shutdown/destroy when _all_ service calls ends", >> but there are a lot of corner cases in such feature. > > Not sure what you mean - the idea was the following: an AppVM opens a > link with `qvm-open-in-dvm` dispName url: > > 1/ if dispName doesn't exist, it is created and a browser (eg. firefox) > pops up with the url. > > 2/ if dispName exists, a new tab is opened in the existing browser (it > is expected that a browser would be running otherwise the dispVM would > be killed because the service call in 1/ would have ended) > > I'd have expected that when the browser is closed by the user the dispVM > would be killed - even if many tabs are open - because the initial > service call in 1/ is "qubes.StartApp+firefox" (or something like that) > and that process/service ended. > Do you mean that in case 2/ service calls "pile up" and that even if the > first service call in 1/ ends the dispVM won't be killed because > subsequent calls are still running ?
I did 2 tests: 1. using "regular" DispVMs - from the Qubes menu, open firefox in a DispVM; 'disp5195' is started. - in my untrusted AppVM, `qvm-open-in-vm disp5195 "http://somesite.com";; a new tab is created in disp5195's firefox. - in my work AppVM, `qvm-open-in-vm disp5195 "http://someothersite.com";; another tab is created in disp5195's firefox. - close firefox -> disp5195 is killed. That's exactly what I need; is that the expected behavior, or am I just being lucky without the "corner cases" you mentioned ? If that's the expected behavior, is there a way to start the dispVM name (eg. dispBrowser) from dom0 instead of getting a random disp[0-9]+ name ? 2. using the way other way you suggested: - create a VM with class DispVM - start it from dom0 with `qvm-run --service dispBrowser qubes.StartApp+firefox` (similar to the .desktop commands of dispVMs in the qubes menu). - open http links from AppVMs as above - close firefox -> dispBrowser isn't killed/shutdown So I get half the behavior I need with each of those tests but I don't manage to combine both - define a DispVM name *and* have the VM killed when the initial service call ends. I just realize that a workaround for case 2/ could be to define a new application shortcut (or systemd unit) that would run firefox and then poweroff when it exits. Or instead of poweroff, ask dom0 to kill it. >>> a comment in vm/__init__.py (line 342) says "when running >>> in dom0, one need to manually kill the dispVM after service call ends" >>> (line 342). Does that mean that AppVMs have to initiate the creation of >>> a dispVM with `qvm-open-in-dvm`, or is it possible to create such >>> dispVMs in dom0 ? >> >>> Another solution would be use create/destroy standard AppVMs but have a >>> dispVM behavior - ie. shutdowning when the service call ends. Is that >>> possible ? I looked at RPC actions but didn't find anything relevant. >> >> You can create a DispVM with a static name. Such VM will not have >> persistent storage (so, all the browser history, cache etc will be gone >> after you shutdown the VM), but you can launch multiple rpc calls, >> without spawning new instance for each. When you decide to close it, you >> can simply choose "shutdown" action in qubes widget, instead of closing >> just the browser. Or combine it with automatic shutdown of inactive VMs: >> https://github.com/QubesOS/qubes-issues/issues/832 >> (there are at least two scripts for this linked there) >> >> To create a DispVM with a static name, use: >> >> qvm-create -C DispVM -t fedora-26-dvm -l red my-static-dispvm > > Thanks for that - I had forgotten that 'DispVM' was a valid class. That > could be a workaround if regular dispVMs can't be used. > > > [1] > https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/ > > [2] https://github.com/Qubes-Community/Contents/issues/24 > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3a803822-07ee-ba2e-df3f-69a719d23fe1%40maa.bz. For more options, visit https://groups.google.com/d/optout.
