-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 02/04/2019 8.04 AM, Ryan Tate wrote:
>> On Apr 1, 2019, at 10:01 PM, Andrew David Wong
>> <
a...@qubes-os.org> wrote: On 01/04/2019 2.54 PM, Ryan Tate
>> wrote:
>>>
>>> If the wish is not “restore” but rather to copy some files —
>>> “some files and scripts that I need” — then it is up to the
>>> user to transfer these files by the usual mechanism.
>>>
>>
>> What is "the usual mechanism"? The main problem with the old
>> behavior was that there was no reasonable way to get the dom0
>> home files out of the backup without clobbering the current dom0
>> home files that you want to keep.
>
> The usual mechanism would be however you would normally move files
> from one machine to another. Not the backup/restore mechanism,
> since he scenario of wanting to move some files and scripts to a
> new machine is not backup/restore.
>
In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
dom0's home and VMs from one machine to another. This is because it is a
violation of the Qubes security model to move files from a less trusted
VM to dom0, and every other VM is, by definition, less trusted than
dom0. Therefore, qvm-backup[-restore] is the only official, secure way
to move files into dom0.
Sure, maybe this doesn't fit some narrow, technical definition of
"restore," but so what? For practical purposes, how does that affect
users in the real world who are trying to get things done securely? If
it really mattered, we could generalize the name to avoid using the word
"restore," but the name doesn't really matter to that degree.
For what it's worth, a lot of dedicated backup software also doesn't
abide by this narrow definition of "restore." For example, a lot of
backup software will deliver your restored files to you as a download,
via email, or in a location other than the original location or computer
from which they were backed up. "Backup and restore" doesn't have to
mean restoring an entire machine state. In Qubes, it's about
user-data-level backup. Using qvm-backup on dom0 is not intended to
duplicate the functionality of lvm snapshot.
> Why is file transport being shoehorned into the backup mechanism?
> In order for some people to use restore for something other than
> restore, I had to spend a bunch of time navigating through obscure
> folders, copying with globs and mv and shunting aside old dirs,
> restarting (multiple times), and crossing my fingers it would
> work. Shouldn’t it be users who are doing strange, non
> backup/restore things who have to jump through hoops, and people
> who simply want to restore dom0 who get helpful default behavior?
>
All you had to do was move everything out of the restored subdirectory:
$ mv home-restore-2019-04-01-etc/* . # move all normal files out
$ mv home-restore-2019-04-01-etc/.* . # move all hidden files out
Simple, quick, and easy, with no weird hoops to jump through.
Now, don't get me wrong. I understand perfectly well that it's only
"simple, quick, and easy" _if you know what to do_ and that this will
_not_ be obvious to many users. But that's precisely why I suggested
that it should be an option via qvm-backup-restore and the GUI tool.
Make it discoverable so that users can understand that there are two
possible outcomes and choose the one they want, then do it for them.
> If people seem open to a change I’ll file an enhancement request.
>
Since I was already writing all this, I just went ahead and opened an
issue for it:
https://github.com/QubesOS/qubes-issues/issues/4946
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlykPh0ACgkQ203TvDlQ
MDBe0w/+MdEEYakxVkGf1fA9lWl0gRM2wByzik0qR6yAjadA0JjdFB6zYNmSoW+7
Y0m2DLQ3N9CtA4dW/hcphJu0ujyNiV4HC0MVdbHPhsOSQSLckJ1wCrXR1zUPYDL2
egsB1cseT7n101y/zZt78DD9iCImurtkQZuF1wRHlYl8iVTgS+nE6BOPOxFd4rns
htX939BJrzhPWPh0etra2c6SupNxBBJgtOieEMkHcFY+BiE9rH36bbia6JWJXDYk
1sVGggUM6LgteqCwKHr9bRB40rpllMLG9/k/uisPvEP9wBj2Z1eMJ8Vro0zcIexF
2aoRy1vMSNZuT49C3T6+ABvdcr+eqN9ahssMSDP5zitqTPZwgncAoPubTRaKmUth
ST/50Cps3Hy7d5aYv8T/h1rClfwlw0c8tctYwFzjaeN45Vqjc7cAZzwv6IKOGPhE
WLcIs46JDHpYbbxi1Tdb1FUYiFVShSUacVzHI+G6tQBVJ3n0Lh3r65ByYhiAexHJ
HksFGMjDaJYF9dYeBwAtXgofCeOgYrIb1MR0Km7SnlRj9Acts/RrmGUS3ep8wm5/
MsLB+ykdujVFKahMi7mtCM717jMaahNCPxnU3gMCIUy8LqUo70vKFDR+xWG6AB6B
piCB6wFYibkJPJjf4DagJJERnj7p6ej53+ZntZ9ZPohI/wfswKE=
=+k1V
-----END PGP SIGNATURE-----