-
Task
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
None
-
False
-
False
-
-
3
-
Testable
-
rhel-conversions
-
-
-
When we create backups of files via RestorableFile so that we can restore the files if we enter rollback, we do it in a way that is non-atomic. This means that saving the file can be interrupted midway through and then, when we enter rollback, the incomplete save can be restored, leading to system corruption
The problem is that in `RestorableFile` we use `shutil.copy2()` to copy the file into the backup location. If we copy to a temporary file in the backup directory first and then use `os.move()` to rename the file into the correct name, we can avoid this issue.
This is the relevant code in backup.py (RestorableFile):
{{
287 def backup(self):
288 """Save current version of a file"""
289 loggerinst.info("Backing up %s." % self.filepath)
290 if os.path.isfile(self.filepath):
291 try:
>>292 loggerinst.debug("Copying %s to %s." % (self.filepath, BACKUP_DIR)) # E: line too
293 shutil.copy2(self.filepath, BACKUP_DIR)
}}
Acceptance Criteria
- Modify RestorableFile.backup():
- copy the file to a temporary file in the BACKUP_DIR. (File renames do not work across filesystems so we need to create the temporary file in the {{BACKUP_DIR}. The {{BACKUP_DIR} is also not world-writable so this mitigates some potential security issues. Using `shutil.copy2()` will preserve many file permissions and metadata so it should continue to be used for the copy.
- Then use `os.move()` to mv the temporary file to its final filename.
1.
|
Creating backups via RestorableFile is non-atomic - Integration tests |
|
New | |
Unassigned |