Orphaned submission files left on disk after restore from backup.

[zenmonkeykstop]

Description

When a SecureDrop backup is restored to the application server, the backup's submission files and database are written to the appropriate locations under /var/lib/securedrop, but existing submission files in /var/lib/securedrop/store are not removed. These submissions are no longer accessible if they do not have corresponding entries in the database that was restored from the backup.

Steps to Reproduce

• on a prod instance (h/w or VMs), create a source with a submission
• back up the instance using ./securedrop-admin backup
• add another source with a submission
• restore from the backup with ./securedrop-admin restore
• inspect the /var/lib/securedrop/store directory on the application server

Expected Behavior

The /var/lib/securedrop/store directory contains only the first source submission

Actual Behavior

The directory contains both source submissions

Comments

The orphaned files will be caught by the nightly check, and admins will be alerted via OSSEC, so this isn't the end of the world. However, it would be good to either a) have the restore remove or move away orphaned files or b) add them back to the database, possibly flagged as "recovered" or something similar.

[conorsch]

Discussed during standup. It appears the issue is longstanding, not a regression introduced as part of 1.3.0, so we'll defer fix until a future sprint. Thanks for the clear write-up, @zenmonkeykstop.