#4683 Restore of encrypted data fails if full path including tarball is provided
Closed: Fixed None Opened 9 years ago by rcritten.

The unencrypted header is needed when doing a restore but the ill-named dirname value may hold the whole path to the file to restore. This causes the opening of the header to fail:

# ipa-restore /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar --gpg-keyring=/root/backup
Directory Manager (existing master) password:

Preparing restore from /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar on ipa.example.com
[Errno 2] No such file or directory: '/var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar/header'

The same command works if only the path is provided:

ipa-restore /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ --gpg-keyring=/root/backup
Directory Manager (existing master) password:

Preparing restore from /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ on grindle.greyoak.com
Restoring data will overwrite existing live data. Continue to restore? [no]: y
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Decrypting /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar.gpg
Stopping IPA services
Restoring files
Restoring from userRoot in EXAMPLE-COM
Restoring from ipaca in EXAMPLE-COM
Starting IPA services
Restarting SSSD
The ipa-restore command was successful

We just want to produce an error message here; we don't want to give people the idea that the tar file is the only thing needed for the restore.

To fix the usability we could make it so that all of the backup data actually is in one file, not in a directory.

IIRC I created the header as a future-proofing device in case we ever provide some sort of scanning tool to make it easier to select what to restore. This would allow us to quickly get a digest of the backups without having to decrypt anything.

I tested and restore fails in both cases (encrypted and not) when passed the tarball.

Ticket is requested by a downstream RHEL release, bumping priority.

master:

  • 373bbee ipa-restore: Check if directory is provided + better errors.

ipa-4-1:

  • b40cf4b ipa-restore: Check if directory is provided + better errors.

Metadata Update from @rcritten:
- Issue assigned to dkupka
- Issue set to the milestone: FreeIPA 4.1.2

7 years ago

Login to comment on this ticket.

Metadata