#2619 Issue closed: Missing BACKUP_DUPLICITY_OPTIONS in restore script

Labels: enhancement, fixed / solved / done, minor bug

GreenBlood opened issue at 2021-05-26 10:07:

Hi, Duplicity restore script seems to be missing the extended arguments from BACKUP_DUPLICITY_OPTIONS on the command line call.

  • ReaR version ("/usr/sbin/rear -V"):
    2.6-git.4355.3a699396.master.changed (still valid in current master)

  • Description of the issue (ideally so that others can reproduce it):

    • Install rear and configure it with a Duplicity backup
    • Include specific BACKUP_DUPLICITY_OPTIONS arguments
      • In my case it was duplicity's --s3-endpoint-url as I don't use AWS S3 storage
    • Build rescue image and start recover
    • Duplicity might fail if the additionnal options are required for the backup data to be accessed (e.g S3 endpoints)

  • Workaround, if any:
    Haven't found any easy one, apart from modifying 400_restore_duplicity.sh by hand (pull request to come)

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
    rear-reard2c.log

As mentionned, I'll create a pull request with what I did on my files to make it work,

Regards

jsmeix commented at 2021-05-27 08:37:

@GreenBlood
I am not a BACKUP=DUPLICITY user so I cannot reproduce or test anything
and all what I write here is only from plain looking at the code.

Could BACKUP_DUPLICITY_OPTIONS while the backup is made
be different compared to options that are needed during restore?
If yes would it perhaps be better to have a separated
BACKUP_DUPLICITY_RESTORE_OPTIONS
config variable or is that overkill?

Could BACKUP_DUPLICITY_OPTIONS contain sectets
like whatever kind of passwords/passphrases or things like that?

jsmeix commented at 2021-05-27 08:45:

@GreenBlood
by the way:

I had a quick look at the counterpart script
usr/share/rear/backup/DUPLICITY/default/500_make_duplicity_backup.sh
I noticed the strange looking DUP_OPTIONS usage therein.
Do you perhaps know why the extra variable DUP_OPTIONS is interposed there
and why not just BACKUP_DUPLICITY_OPTIONS is directly used as is?
To me this looks like yet another RFC 1925 item 6a implementation
"It is always possible to add another level of indirection".

GreenBlood commented at 2021-05-27 11:25:

@jsmeix

If yes would it perhaps be better to have a separated
BACKUP_DUPLICITY_RESTORE_OPTIONS
config variable or is that overkill?

Looking at the arguments listings, I'm not sure this would be very helpful, but I'm not a very advanced duplicity user either so I may not see the full picture. Anyway adding a restore-specific option (maybe "cloning" it from backup options by default) does not seems technically very hard.

Could BACKUP_DUPLICITY_OPTIONS contain sectets

Encryption password are generally either prompted when running the command, or passed through environment variable. For example the basic case, rear uses the setting named "BACKUP_DUPLICITY_GPG_ENC_PASSPHRASE", which is transferred to "PASSPHRASE" when passed to duplicity ( https://github.com/rear/rear/blob/master/usr/share/rear/backup/DUPLICITY/default/500_make_duplicity_backup.sh#L41 ).

Likewise, in my case the backup storage backend I'm authenticating against is an cloud object storage and I have to use environment variables to connect to it, as there is no specific option to do that.

Some duplicity options are security-related (like specifying which GPG key to use when using asymetric encryption) but from what I can see in the arguments, nothing ressembling a passphrase or something that would be VERY private.

I had a quick look at the counterpart script
usr/share/rear/backup/DUPLICITY/default/500_make_duplicity_backup.sh
I noticed the strange looking DUP_OPTIONS usage therein.
Do you perhaps know why the extra variable DUP_OPTIONS is interposed there
and why not just BACKUP_DUPLICITY_OPTIONS is directly used as is?
To me this looks like yet another RFC 1925 item 6a implementation
"It is always possible to add another level of indirection".

I saw this variable usage too and assumed it was related to the # todo: check parameters a few lines above. But like you said, is it seems there is no other processing of those variable involved, it looks to me that both variable are exactly the same. (BKP_URL in the same file has the same weird usage)

jsmeix commented at 2021-05-27 13:04:

Regarding BACKUP_DUPLICITY_GPG_ENC_PASSPHRASE
it seems the ENC therein does not mean the passphrase value is encrypted therein
but that it contains the unencrypted passphrase to ENCrypt the backup
as far as I can imagine what its little comment in default.conf means.

When a variable can contain a secret value special code is needed
to avoid that the secret value leaks out, see the issue
https://github.com/rear/rear/issues/2155
and the special code that is used to fix it in
https://github.com/rear/rear/pull/2156

jsmeix commented at 2021-05-28 13:17:

With https://github.com/rear/rear/pull/2620 merged
this issue should be fixed.

https://github.com/rear/rear/issues/2619#issuecomment-849617528
will be done separatedly

@GreenBlood
thank you for your issue report and even more thanks for your fix!

[Export of Github issue for rear/rear.]