sudo drops SILTA_CONFIG/HOME, so privileged commands can resolve the wrong config #5

New issue

Closed

opened 2026-08-11 10:25:37 +00:00 by aav · 0 comments

aav commented

2026-08-11 10:25:37 +00:00

Owner

Removing the required positional CONFIG argument (src/main.rs:78) lets privileged subcommands silently resolve a different config than the one run/setup used, because sudo's env_reset drops SILTA_CONFIG and resets HOME.

Failure scenario: a user works with export SILTA_CONFIG=~/Work/pxy/netzlive-addr.toml, runs silta run (works), then runs sudo silta update or sudo silta teardown with no --config. sudo strips SILTA_CONFIG and sets HOME=/var/root, so config_path resolves /var/root/.config/silta/config.toml. Best case the command fails with "reading ... No such file"; if a different config exists there, update reconciles the wrong interface and removes as "extra" the very addresses the live run instance is bound to, so active forwards stop accepting connections. The old CLI made this impossible: every privileged command had to name its config explicitly.

Fix direction: for privileged subcommands, require an explicit --config (or otherwise detect that the default path was reached via a reset environment) rather than silently falling back.

Source: high-effort code review, CONFIRMED. Area: cli.

Removing the required positional CONFIG argument (src/main.rs:78) lets privileged subcommands silently resolve a different config than the one `run`/`setup` used, because sudo's env_reset drops SILTA_CONFIG and resets HOME. **Failure scenario:** a user works with `export SILTA_CONFIG=~/Work/pxy/netzlive-addr.toml`, runs `silta run` (works), then runs `sudo silta update` or `sudo silta teardown` with no --config. sudo strips SILTA_CONFIG and sets HOME=/var/root, so `config_path` resolves `/var/root/.config/silta/config.toml`. Best case the command fails with "reading ... No such file"; if a different config exists there, update reconciles the wrong interface and removes as "extra" the very addresses the live run instance is bound to, so active forwards stop accepting connections. The old CLI made this impossible: every privileged command had to name its config explicitly. **Fix direction:** for privileged subcommands, require an explicit --config (or otherwise detect that the default path was reached via a reset environment) rather than silently falling back. Source: high-effort code review, CONFIRMED. Area: cli.

aav added the

bug

priority

major

labels

2026-08-11 10:25:37 +00:00

aav self-assigned this

2026-08-11 10:27:24 +00:00

aav referenced this issue from a commit

2026-08-11 11:03:14 +00:00

Require an explicit config for privileged subcommands

aav closed this issue