encryption_passcommand in one config file A wrongly used for repo in config file B #555

New Issue

Closed

opened 2022-06-30 09:25:32 +00:00 by real-or-random · 4 comments

real-or-random commented 2022-06-30 09:25:32 +00:00

Copy Link

What I'm trying to do and why

I have multiple config files, say A.yaml and B.yaml (sanitized). I want to run borg check on a repo in B.yaml, specifying the repo using --repository.

Steps to reproduce (if a bug)

Relevant snippets of the config files:

A.yaml:

location:
    repositories:
        - /repo/A        
storage:
    encryption_passcommand: secret-tool lookup  ... 

B.yaml:

location:
    repositories:
        - /repo/B
storage:
    #encryption_passcommand unset 
    #encryption_passphrase unset

No merging/YAML magic in the config files.

Actual behavior (if a bug)

borgmatic --repository /repo/B borg check ... aborts with "passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect.".
strace shows that borg runs the encryption_passcommand from A.yaml before aborting.

borgmatic --config /etc/borgmatic.d/B.yaml --repository /repo/B borg check ...

Expected behavior (if a bug)

borgmatic --repository /repo/B borg check ... ignores everything in A.yaml and asks for a passphrase

Other notes / implementation ideas

Not sure if this is specific to arbitritrary borg commands / borg check. I vaguely remember that I saw this problem with normal operations in the past but I never really bothered reporting it. I can't try right now because the borg check is in progress now... ;) I can try later if this is relevant.

Environment

borgmatic version: 1.6.4

borgmatic installation method: Arch Linux package

Borg version: 1.1.17

Python version: 3.10.5

operating system and version: Arch Linux

#### What I'm trying to do and why I have multiple config files, say A.yaml and B.yaml (sanitized). I want to run borg check on a repo in B.yaml, specifying the repo using `--repository`. #### Steps to reproduce (if a bug) Relevant snippets of the config files: A.yaml: ``` location: repositories: - /repo/A storage: encryption_passcommand: secret-tool lookup ... ``` B.yaml: ``` location: repositories: - /repo/B storage: #encryption_passcommand unset #encryption_passphrase unset ``` No merging/YAML magic in the config files. #### Actual behavior (if a bug) `borgmatic --repository /repo/B borg check ...` aborts with "passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect.". `strace` shows that borg runs the `encryption_passcommand` from A.yaml before aborting. `borgmatic --config /etc/borgmatic.d/B.yaml --repository /repo/B borg check ...` #### Expected behavior (if a bug) `borgmatic --repository /repo/B borg check ...` ignores everything in A.yaml and asks for a passphrase #### Other notes / implementation ideas Not sure if this is specific to arbitritrary borg commands / borg check. I vaguely remember that I saw this problem with normal operations in the past but I never really bothered reporting it. I can't try right now because the borg check is in progress now... ;) I can try later if this is relevant. #### Environment **borgmatic version:** 1.6.4 **borgmatic installation method:** Arch Linux package **Borg version:** 1.1.17 **Python version:** 3.10.5 **operating system and version:** Arch Linux

witten added the

bug

label 2022-06-30 17:11:32 +00:00

witten commented 2022-06-30 17:19:56 +00:00

Owner

Copy Link

Thank you for bothering to report this! 😄 I have a hunch about what's going on here. Things like Borg passcommands are communicated from borgmatic to Borg via environment variable. So borgmatic is probably setting the passcommand environment variable for repository A and then it's still around when it gets to repository B, causing the behavior you're seeing.

The fix is probably to avoid altering the global environment and instead pass in a local environment specific to each Borg command that it runs. (More specifically, execute_command(extra_environment=....) The trick will be plumbing that through everywhere that needs it set.

Thank you for bothering to report this! 😄 I have a hunch about what's going on here. Things like Borg passcommands are communicated from borgmatic to Borg via environment variable. So borgmatic is probably setting the passcommand environment variable for repository A and then it's still around when it gets to repository B, causing the behavior you're seeing. The fix is probably to avoid altering the global environment and instead pass in a local environment specific to each Borg command that it runs. (More specifically, `execute_command(extra_environment=...`.) The trick will be plumbing that through everywhere that needs it set.

witten referenced this issue from a commit 2022-06-30 20:43:15 +00:00

Fix environment variable plumbing so options in one configuration file aren't used for others (#555).

witten commented 2022-06-30 20:43:50 +00:00

Owner

Copy Link

Okay, it took some doing, but this should be fixed. Environment variables are no longer set globally, so they should be scoped to particular configuration files now. Release forthcoming. Thanks again for reporting this!

Okay, it took some doing, but this should be fixed. Environment variables are no longer set globally, so they should be scoped to particular configuration files now. Release forthcoming. Thanks again for reporting this!

witten closed this issue 2022-06-30 20:43:50 +00:00

witten commented 2022-07-01 05:17:23 +00:00

Owner

Copy Link

Fix released in borgmatic 1.6.5!

Fix released in borgmatic 1.6.5!

real-or-random commented 2022-07-01 09:33:25 +00:00

Author

Copy Link

Thanks for the quick fix!

Thanks for the quick fix!

witten referenced this issue 2023-03-28 23:12:36 +00:00

How to prevent repeating output of the same by list, info, ... commands #479

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#555

No description provided.