borgmatic-collective / docker-borgmatic

Borgmatic in Docker
GNU General Public License v3.0
354 stars 93 forks source link

Passphrase env vars with special characters no longer work with 1.8.13 #346

Open witten opened 2 months ago

witten commented 2 months ago

As of docker-borgmatic 1.8.13, some Borg passphrases that worked fine with 1.8.12 no longer work. For instance:

$ docker run --rm -e BORG_PASSPHRASE='`' ghcr.io/borgmatic-collective/borgmatic:1.8.13
[custom-init] Docker CLI variable not set, skipping...
[custom-init] No custom packages found, skipping...
/etc/s6-overlay/env/cron-env: line 1: unexpected EOF while looking for matching ``'
-----------------------------------
Software Versions:
...

Which, if cron is actually configured and runs, leads to a Borg error about: passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect.

Whereas with 1.8.12:

$ docker run --rm -e BORG_PASSPHRASE='`' ghcr.io/borgmatic-collective/borgmatic:1.8.12
[custom-init] Docker CLI variable not set, skipping...
[custom-init] No custom packages found, skipping...
-----------------------------------
Software Versions:

And then if cron is actually configured, the passphrase comes through correctly and there's no error from Borg.

I believe the problem was likely introduced in #331 and specifically in https://github.com/borgmatic-collective/docker-borgmatic/pull/331/files#diff-df5fc4ba71d9f961534c2d65215e50da1befb1f2a16c4a03c58eba442f8c5dc3

It's possible that a backtick is not the only special character broken in this way by 1.8.13.

YabaiKai commented 2 months ago

I agree. I've had significant issues with Borgmatic starting to declare my password incorrect, after having worked for the past 6 months at least. I'm convinced this is part of the problem. After painstaking review, I figured out that the issue was the BORG_PASSPHRASE environment variable in my docker compose file. In the past I had it set to BORG_PASSPHRASE="mypassword", but not it only works when I take out the quotes, i.e. BORG_PASSPHRASE=mypassword.

I'm guessing this is related. The README and documentation still has quotes, and I think this needs to be changed.

917huB commented 2 months ago

My backups started failing when called from CRON with 1.8.13 too, 'passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect.'. Passcode fails regardless whether its included in quotes or not. If I log into the container, echo $BORG_PASSPHRASE shows the correct string that includes the following special characters &^*$#@. If i call borg from the command line it works fine, i.e docker exec borgmatic sh -c "borgmatic -c /etc/borgmatic.d/example.yaml --verbosity 1 --files"

EDIT: 9/5/24 failing in 1.8.14 too.

SECtim commented 1 month ago

I observe similar issues with passphrases that contain something like $0.

However, the root cause depends on the special character. With characters like " and backticks, the following line fails immediately: https://github.com/borgmatic-collective/docker-borgmatic/blob/8adec5d7c8d906fda2200c170d4db2a961d02428/root/etc/s6-overlay/s6-rc.d/secrets/run#L22

Whereas with stuff like $0, the issue is in the following lines (when using BORG_* environment variables, but a similar issue seems to exist for *_FILE variables): https://github.com/borgmatic-collective/docker-borgmatic/blob/8adec5d7c8d906fda2200c170d4db2a961d02428/root/etc/s6-overlay/s6-rc.d/secrets/run#L58-L59

While the contents of the resulting /etc/s6-overlay/env/cron-env look correct in the second case (e.g., export BORG_PASSPHRASE="my$0passphrase") the double quotes around the value lead to another round of shell expansion for the cron environment - in the example above, this results in a BORG_PASSPHRASE value of my/runpassphrase.

I am unsure whether this expansion behavior is on purpose, maybe @Psycho0verload can comment on that - depending on the intended behavior, either code or documentation should be adjusted. My personal take is: the borgmatic image should make no assumptions at all about the passphrase (which requires some very careful handling of the passphrase in shell scripts).

Psycho0verload commented 1 month ago

@SECtim It's been a few days now. I suspect that I also had problems with the special characters and that's why I put it in quotation marks.

I've seen that Linuxserver.io also works mainly with S6-overlay, and there are Secrets implemented by default. It's very cleanly written there and I'll test if that's not the better option for borgmatic as well.

SECtim commented 1 month ago

I am by no means a shell guru, but I suppose single quotes instead of double ones in the cron-env file would already solve most of the issues - except of course when the value itself contains single quotes, then these have to be escaped (I am not aware of a ready-to-use POSIX function to do so, but once again, I am not that familiar with shell programming).

Psycho0verload commented 1 month ago

No problem, I am currently testing a different type of Secrets integration. The way it is used by linuxserver.io. that could help :)

Psycho0verload commented 1 month ago

Just for your information. I am still on vacation. I will start working on this ticket again next week ;-)

eeak commented 6 days ago

I encountered this problem. I spent a lot of time trying to find where I went wrong. Until I found this issue. I rolled back to 1.8.12. Is there any news?

Psycho0verload commented 1 day ago

I am current working on this