Backup verification leaves files in dom0 home directory

[andrewdavidwong]

How to file a helpful issue

Qubes OS release

4.2

Brief summary

After verifying a backup, Qubes leaves leftover files in the user's dom0 home directory.

Steps to reproduce

Use the GUI backup restore tool to verify the integrity of a backup file that resides in an app qube.

Expected behavior

1. Qubes OS shouldn't put files in the user's home directory without user consent and informing the user.
2. Qubes OS should clean up after itself, not leave temp files lying around.

Actual behavior

There is an unexpected leftover QubesIncoming/ directory in the user's dom0 home directory containing some files related to the operation. It is not clear why this exists or what it's for unless you're at least somewhat familiar with how the backup verification process works.

Commentary

The home directory is the one place in the system where users are told to store their own personal files. Users should be able to expect to exercise full control over that one directory. The entire directory should be considered "user data." Finding files there that the user did not put there can be alarming and could be an indicator of compromise. At no point during the backup verification process is the user warned or informed that any files will be created in the dom0 home directory. The system should never touch that directory as part of its own internal operations. (It has the whole rest of the file system to work with.) Even if it does have to touch the user's data for some reason, it should clean up its own temp files after it's done, not force the user to clean up after it.

[alimirjamali]

The directory names should be backup#restore-RANDOMNUMBER.

Did the Qubes Backup Restore verification finish successfully or was cancelled (or maybe crashed)?

[andrewdavidwong]

The directory names should be backup#restore-RANDOMNUMBER.

Yep.

Did the Qubes Backup Restore verification finish successfully or was cancelled (or maybe crashed)?

Finished successfully.

[alimirjamali]

There was a fix two years ago which selected the QubesIncoming directory as the temporary directory for backup operations (Maybe using something like QubesBackupRestore would help to avoid confusion in some cases). That fix uses mkdtemp function to create temporary work sub-directories. And those sub-directories should be automatically deleted after the application is closed (unless the file is open in another process).

After removing the existing QubesIncoming (and the backup#restore* sub-dirs), I tested verification of some backups and the temp sub-directories were successfully deleted after the application was closed.

Since I have never verified any backup on this machine but had some of those left-over temp sub-dirs, My hypnosis is that those temp directories might not be left during verification phase. But during backup itself.

It is not that easy. There are zombie defunct qubes-backup-restore sub-processes after verification has finished.

[andrewdavidwong]

There was a fix two years ago which selected the QubesIncoming directory as the temporary directory for backup operations (Maybe using something like QubesBackupRestore would help to avoid confusion in some cases).

Why does it have to use the user's home directory at all? Why can't it use something like /tmp/ or /var/tmp/?

[alimirjamali]

Why does it have to use the user's home directory at all? Why can't it use something like /tmp/ or /var/tmp/?

The technical reason is mentioned in that PR comment two years ago. It was because of an issue with SELinux policy. Otherwise the work directory was /var/tmp before that. One way to fix it would be reverting to /var/tmp and ship a dedicated SELinux policy to enable working in that directory (which is a good idea IMO).

Technically all of the the temporary files are unlinked (deleted) in the code and the temporary directory is created via mktemp function which should vanish after the program is closed. But since the GUI backup is a multi-thread program, it is complex. This is one of those issues that will take some time to fix properly as I have to familiarize myself with the entire mechanism. I am working on it. While I am at it, I am working on other improvements to the backup & restore GUI.

These are what I am currently working on:

• Adding most of the command line options of their CLI counterparts.
• Adding a drop-down menu to allow selection of compression algorithm
• Minor fixes and improvements.