fix: config path advisory ignores XDG file on interactive root (#81) #83

Merged
razvandimescu merged 1 commits from fix/config-path-advisory into main 2026-04-12 07:17:33 +08:00
razvandimescu commented 2026-04-12 07:05:12 +08:00 (Migrated from github.com)

Summary

  • The bug (#81): Port-53 and TLS-data-dir advisories told users to create ~/.config/numa/numa.toml, but config_dir() routed root to /var/lib/numa/ and load_config never consulted the XDG path — so the file the user created was silently ignored. The advisory and the code disagreed about where the config lives.
  • The fix: new suggested_config_path() helper in src/lib.rs prefers $HOME/.config/numa/numa.toml when HOME is set (and isn't / or empty), with config_dir() as a lazy fallback. Wired into both advisories and into load_config as an additional candidate, so the advised path is the one Numa actually reads.
  • Scope: config_dir() and data_dir() are deliberately unchanged. Runtime state (services.json, TLS CA) stays in FHS so an interactive-root session that later runs numa install keeps continuity with the installed daemon.
  • No regression for existing installs: load_config candidate order is still (cwd, config_dir, data_dir, suggested). The XDG candidate is appended last, so any pre-existing FHS/Homebrew-prefix config (e.g. macOS /usr/local/var/numa/numa.toml) still wins as before. Verified in the docker regression scenarios.

Test plan

  • cargo test --lib — 210 passed (6 new unit tests around resolve_suggested_config_path covering interactive user, interactive root, unset/empty// HOME, and lazy-fallback short-circuit)
  • cargo clippy -- -D warnings — clean on touched files
  • cargo fmt --check — clean
  • cargo audit — clean
  • ./tests/integration.sh release — 68/68 passed
  • ./tests/docker/issue-81.sh — 4/4 scenarios match expectations:
    • replication/main — user creates ~/.config/numa/numa.toml, main ignores it (bug confirmed)
    • replication/fix — user creates it, fix loads it and binds 127.0.0.1:5354
    • existing/main — pre-placed FHS config still loads (baseline)
    • existing/fix — pre-placed FHS config still loads (no regression)

Closes #81.

## Summary - **The bug (#81):** Port-53 and TLS-data-dir advisories told users to create `~/.config/numa/numa.toml`, but `config_dir()` routed root to `/var/lib/numa/` and `load_config` never consulted the XDG path — so the file the user created was silently ignored. The advisory and the code disagreed about where the config lives. - **The fix:** new `suggested_config_path()` helper in `src/lib.rs` prefers `$HOME/.config/numa/numa.toml` when `HOME` is set (and isn't `/` or empty), with `config_dir()` as a lazy fallback. Wired into both advisories and into `load_config` as an additional candidate, so the advised path is the one Numa actually reads. - **Scope:** `config_dir()` and `data_dir()` are deliberately unchanged. Runtime state (`services.json`, TLS CA) stays in FHS so an interactive-root session that later runs `numa install` keeps continuity with the installed daemon. - **No regression for existing installs:** `load_config` candidate order is still `(cwd, config_dir, data_dir, suggested)`. The XDG candidate is appended last, so any pre-existing FHS/Homebrew-prefix config (e.g. macOS `/usr/local/var/numa/numa.toml`) still wins as before. Verified in the docker regression scenarios. ## Test plan - [x] `cargo test --lib` — 210 passed (6 new unit tests around `resolve_suggested_config_path` covering interactive user, interactive root, unset/empty/`/` HOME, and lazy-fallback short-circuit) - [x] `cargo clippy -- -D warnings` — clean on touched files - [x] `cargo fmt --check` — clean - [x] `cargo audit` — clean - [x] `./tests/integration.sh release` — 68/68 passed - [x] `./tests/docker/issue-81.sh` — 4/4 scenarios match expectations: - `replication/main` — user creates `~/.config/numa/numa.toml`, main ignores it (bug confirmed) - `replication/fix` — user creates it, fix loads it and binds `127.0.0.1:5354` - `existing/main` — pre-placed FHS config still loads (baseline) - `existing/fix` — pre-placed FHS config still loads (no regression) Closes #81.
Sign in to join this conversation.