I’m experimenting with the concept of a reverse ~/QubesIncoming folder, something like ~/QubesOutgoing, where you put some files and that triggers automatically a qvm-move (-to-vm) operation. It’s quite useful for screenshots, saving something from an app and sending it to somewhere else. It is still buggy, and even if I tried to do some research before but maybe with the wrong terms, so now I’m wondering if I might be reinventing the wheel…
Do you have an example of something similar?
Cool idea. Here are a few things to consider:
Maybe use cron to check from time to time.
Configure the Qubes RPC policy so the file move does not require confirmation.
Verify that the file is not being written to before moving it.
Ensure you handle unsuccessful moves, such as when the file already exists in the target qube.
I’m using a systemd path unit.
That’s not my use case and it would add complexity that I’m not sure to be able to handle.
I haven’t thought about that, thanks!
I’m unsure about what to do in that case: remove the file? move it somewhere else? keep it in the special folder?
Some time ago @apparatus gave me the idea about qvm-copy-from which may be related (or not) to what you are working on. I haven’t had the time to experiment with it yet but in case you are interested:
I also remember seeing a guide about rsync between qubes which may also work.
Is it legit to think that this could be a potential security risk, where in the compromised qube, this folder would be searched for in order to put there malicious “screenshot”. I am not claiming, just risk assesing…
Solid choice
Generate a error notification but keep the file in the directory
That’s a users problem to solve. qvm-copy would fail, so also generate a error notification
Any actor with the rights to move/create a file in that directory would anyway be able to call qvm-copy - therefore no issue
I was thinking more of a not thinking too much when I am in that directory.- - taking its content for the grant?
Same, no issue - you argue about the receiving end, that one can always get a file send if not other specified by a policy.
Thanks. It bugs me somehow and I don’t know why in spite any logic.
It’s actually quite easy. In dom0, create a file named /etc/qubes/policy.d/20-automove.policy containing the following line:
qubes.Filecopy * QUBES-FROM QUBES-TO allow
Now, if you run qvm-move-to-vm QUBES-TO file inside QUBES-FROM, it will proceed immediately without asking for confirmation.
(Note: Replace QUBES-FROM and QUBES-TO with the actual names of the qubes involved. Also, ensure this rule is placed in a file with a lower number (e.g., 20) than the default policy
(usually 90) so it takes precedence.)
Well, I have my answer: it is not that obvious 
Thanks for the ideas, some of them don’t fit well with my use case because, what I want to avoid is the situation where inside a software, I only have the option to “Save”, and then:
After this, it is a regular qvm-move... workflow, with custom policies or not. Right now, one of the current bugs is my GTK window in dom0, the one to choose the target of the qvm-move-to-vm command. It works, kind of, but I don’t know how to make it work when launched by the systemd service. With your ideas, I’m now thinking about using a named disposable target qube just for that, acting as a proxy, where dom0 then moves the file to the ~/QubesOutgoing directory of the disposable.
I would speculate, that dialog appears because of the policy which is set to ask. Surely a good tool when wanting to have something dynamic.
In your case I would argue, it would be sufficient to just have a script (executed by systemd) that picks the file and based on the directory name sends it to its target. Where the same for dom0 applies as a sender but with qvm-move-to-vm instead of just qvm-move.
Therefore I don’t see a reason for needing a disposable vm for anything.
Also, just wanting to make sure, please don’t invent a way for a vm so send something to dom0
I’m building my own dialog in dom0 because qvm-move-to-vm requires the name of a qube. In any other qube, it’s just a wrapper around qvm-move
Having ~/QubesOutgoing/<POTENTIAL_TARGET> in dom0 is indeed a potential workaround.
It did me too - even though @balder86 is 100% correct about the Qubes-side risk.
I think it is because the whole idea tempts the mind towards further automation of file handling in the target qube, which could effectively automate the user-side risk.
I like the manual step where I ask myself “Why has has been qvm-copy/moving files here?” before I touch them and it would be easy -but wrong for my threat model(s)- to remove that also.
You are right - my mistake. Inter-vm transfers really do invoke the dialog due to the ask policy. I’m sorry …
I had a closer look at the situation and found a way how the script could behave somewhat similar between dom0 and qubes in regards of having a common QubesOutgoing folder + the dialog to choose a target.
It seems there is no way to force the native dialog in dom0. But one can create a dialog with the qubes to choose from - semi the same.
qvm-ls --raw-list | grep -v dom0 | sort | zenity --list --title="Select target VM" --column "Qube"
What you get is the name of the choosen vm which you could then use for qvm-move-to-vm
well if you have ~/QubesOutgoing/browser, then it would suggest browser as destination, which means you dont have to write “browser” before confirming it, which is not in line with Qubes security policy for copying files (user has to explicitly state the destination VM).
If you don’t its kinda useless.
About the very first part of the command, I also removed anything not having the AppVM or DispVM classes + not running or paused to keep it short. I will try that zenity command, thanks!
@kuhbs, my current issue is mostly about dom0 (qvm-move-to-vm, not qvm-move), where you have to specify the qube.
Ah! Ok for dom0 that makes sense.
Kinda like mv file.txt ~/QubesOutgoing/browser and then it does the rest via systemd magic? That makes sense to me, but I don’t really see the usecase.
Screenshots you can do with xfce4-screenshooter in the VMs individually, you don’t need to take screenshots in dom0 unless you want to actually capture the whole screen and not just one VMs screen (which should be rare).
Just do a uname -n, you will get the nodename, in case of dom0 - simply dom0. Then a little if/else to change the behavior, et voila.
@balder86 thank you for noticing