And there appeared one interesting question.
Upon the creation of an external LUKS2 volume in one of my qubes, there appears a header file that is by default permitted to be read by root only. Normal procedure (GUI, from context menu in file manager) of copying the file into another VM won’t work.
What ways would you suggest for backing it up both to another qube and to an external USB drive?
I have thought of one or two ways. But I suspect there can be better ones.
Pardon my further question (as I could have tried to figure it out myself).
What arguments should follow the ‘qvm-copy’? Obviously the source file must be there. Anything else?
Does it copy the file to any kind of inter-qube tmp partition before it’s actually saved in the destination qube? From the point of view of security, it must be impossible to copy files to other VMs solely with entering commands in the source VM.
It is dependent on the policy set in /etc/qubes/policy.d/90-default.policy
There you will see entry for qubes.FileCopy - the policy set here, or
overridden by you in another policy file, governs what transactions
between qubes or groups of qubes are allowed.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
There are basically three methods that I’d consider if it were me:
Simply back up the entire qube with qvm-backup (or GUI equivalent).
Use qvm-copy as root, as described by others above.
Change the permissions on the file, then use qvm-copy (or whatever you want to do) normally. User/root separate inside of an app qube is a controversial issue, but many Qubes devs historically have not considered it to be a very strong security boundary, so they’d probably say you don’t gain much by trying to preserve the file’s root-only permissions in this context (especially if that’s all you’re doing in this qube).