Skip to content

security: same local repo dir via another path is not a relocation, fixes #8188 - #10516

Merged
ThomasWaldmann merged 1 commit into
borgbackup:masterfrom
ThomasWaldmann:same-repo-dir-8188
Oct 11, 2026
Merged

ThomasWaldmann merged 1 commit into
borgbackup:masterfrom
ThomasWaldmann:same-repo-dir-8188

Conversation

@ThomasWaldmann

Copy link
Copy Markdown
Member

Fixes #8188.

The "repository was previously located at" check in SecurityManager.assert_location_matches() compared path strings only (after the NFC/NFD normalization from #2913). So reaching the same local repository directory via a different path looked like a relocation:

  • a symlink (bar -> foo)
  • a bind mount
  • a different letter case on a case-insensitive filesystem (e.g. FOO vs foo on macOS APFS)

Answering "yes" rewrote the stored location, so alternating between the paths kept re-triggering the prompt, which breaks unattended runs (e.g. prune).

Change

If the path strings differ, borg now also checks whether both are local paths referring to the same existing directory (os.stat + os.path.samestat). If they do, there is no warning.

  • The stored location and all displayed paths are unchanged. Nothing is resolved or rewritten, so the output never shows a path the user did not type.
  • It only applies to local (file) repositories with an absolute previous path. ssh:// and other URL locations are never affected.
  • If the old path no longer exists (a real move/rename), the warning appears as before.
  • Filesystems reporting st_ino == 0 are never treated as "same".

With borg 2's AEAD session keys, a copied repo is not a nonce-reuse risk, so skipping the warning when both paths provably are the same directory loses nothing.

Tests

  • New test_repository_access_via_symlink accesses the repo via its path, then a symlink, then its path again, with BORG_RELOCATED_REPO_ACCESS_IS_OK=no. It expects no abort and an unchanged stored location. The test fails without the fix.
  • The existing test_repository_move still covers a real rename triggering the warning.
  • Manually checked on case-insensitive APFS: foo, FOO and a symlink bar give no prompt; after mv foo moved the prompt still appears.

The FAQ entry "How do I rename a repository?" got one sentence about this.

🤖 Generated with Claude Code

@codecov

codecov Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.25%. Comparing base (185c5a3) to head (a879f5c).
⚠️ Report is 38 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #10516   +/-   ##
=======================================
  Coverage   89.25%   89.25%           
=======================================
  Files         104      104           
  Lines       19893    19941   +48     
  Branches     3118     3127    +9     
=======================================
+ Hits        17756    17799   +43     
- Misses       1478     1482    +4     
- Partials      659      660    +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

…ixes borgbackup#8188

The "repository was previously located at" check compared path strings only,
so reaching the same local repository directory via a symlink, a bind mount or
a different letter case on a case-insensitive filesystem looked like a
relocation. Answering yes rewrote the stored location, so alternating between
the paths kept triggering the prompt (breaking e.g. unattended prune).

If the strings differ, but both are local paths referring to the same existing
directory (same st_dev/st_ino, st_ino != 0), do not warn. The stored location
and all displayed paths stay as they were. Remote locations are not affected,
and a real move/rename (old path gone) still triggers the warning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ThomasWaldmann
ThomasWaldmann merged commit 0ff5aa9 into borgbackup:master Oct 11, 2026
25 of 26 checks passed
@ThomasWaldmann
ThomasWaldmann deleted the same-repo-dir-8188 branch October 11, 2026 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Canonical path: resolve symbolic links?

1 participant