dom0 has qvm-copy-to-vm, but inside vm it doesn’t work exactly the same as it does in dom0. I am prompted to select the target vm in the pop-up gui window and it is VERY inconvenient. How do I copy a file or directory without gui? Or from the dom0 command line?
I see it as a safety step, but maybe it is overlooked by developers…
the way to copy and paste from vm to DOM0 to vm is control + C → shift + control + C → shift + control + V → control + V or [paste]
it will never work
the way to copy and paste from vm to DOM0 to vm is control + C → shift + control + C → shift + control + V → control + V or [paste]
That is not true. You can’t copy and paste in and out of dom0.
To avoid the permission prompt when qvm-copying from inside a VM:
- use
qvm-copy-to-vm TARGETVM FILE - allow SRCVM → TARGETVM in qubes policy:
For Qubes 4.1,/etc/qubes/policy.d/30-user.policycontaining
qubes.Filecopy * SRCVM TARGETVM allow
For Qubes 4.0,/etc/qubes-rpc/policy/qubes.Filecopycontaining
SRCVM TARGETVM allow
In the above, SRCVM and TARGETVM should be replaced by the actual VM names. You don’t need to restart any VMs for the policy to take effect.
2 Likes
Your syntax is slightly confusing. You say qvm-copy-to-vm TARGETVM FILE where “TARGETVM” and “FILE” are variables that are replaced with an actual VM name and file path. Then you say to put qubes.Filecopy * SRCVM TARGETVM allow inside of 50_user.policy
Does this mean that only specific source VMs and target VMs are allowed to interVM copy without a GUI prompt? I assume not.
The problem for me is that neither qubes.Filecopy * SRCVM TARGETVM allow nor (for example) qubes.Filecopy * vault personal allow work for me in 4.1…
Do I need to restart Qubes for the changes to take effect?
Sorry, should be fixed.
qubes.Filecopy * vault personal allow should work.
Are you sure you’re using qvm-copy-to-vm instead of qvm-copy?
The syntax or Qubes? 
Like I said, neither format works when I edit 30_user.policy
Are you using the qvm-copy-to-vm command?
Sorry… my mistake. I created 30_user.policy instead of 30-user.policy. 
It’s working now.
I used:
qubes.Filecopy * @anyvm @anyvm allow
So it will work between any two VMs. Hopefully that is not a significant security issue.
Uh, that allows any VM to any VM, so big security issue?
Just do
qubes.Filecopy * vault personal allow
if you want vault → personal.
Well, honestly I would rather the convenience of general interVM transfers by command line. Do you think it creates a significant security risk?
The more I think about it, the more I think it does create a significant security risk. It would potentially allow a malicious script to defeat the compartmentalization that secures each VM. As “annoying” as the prompt is, it forces user interaction to allow transfers.
2 Likes
I mean, it allows any qube to transfer to any other qube without prompting. Though it only writes into ~/QubesIncoming of the destination qube. Who knows, maybe something in the destination qube processes files in ~/QubesIncoming automatically (like a file indexer, file manager thumbnail generator, …).
Yeah, I’m going to change it back. It’s only annoying when I’m trying to copy many things. Thanks for your help!
I myself allow certain high-trust qubes to transfer to low-trust qubes without approval. But I don’t use wildcards like @anyvm, just specific (srcvm,destvm) pairs, in my filecopy policy,
1 Like
well, I run some programs that require you to read the config from the file but I feed them the config from stdin, but in the case of the current problem it does not work…
qvm-run --pass-io sourceVM 'cat file' | qvm-copy-to-vm destVM /dev/stdin
What do you think about that?
assuming you are running this in dom0:
qvm-run --pass-io sourceVM 'cat file' | qvm-run --pass-io destVM 'mycommand'
will pass contents of file in sourceVM to to stdin of mycommand in destVM