reset-dashboard resolves its rm -rf targets from current config.json, not the live .env — a config edit before reset can wipe the wrong dir

[VijitSingh97]

Summary

reset_dashboard calls parse_and_validate_config (which re-reads config.json and re-resolves P2POOL_DIR/DASHBOARD_DIR), then sudo rm -rf on those paths. The targets come from current config.json, not from .env (what the running stack actually uses). assert_safe_dir only blocks obviously-catastrophic paths (/, /root, …); it doesn't verify the dir is one the stack created/owns.

Evidence

• pithead reset_dashboard (~lines 407-419) — parse_and_validate_config then sudo rm -rf "$DASHBOARD_DIR" / "$P2POOL_DIR".
• assert_safe_dir (~line 703) — blocklist only.

Impact

If an operator edits p2pool.data_dir/dashboard.data_dir in config.json but hasn't run apply yet, reset-dashboard deletes the new path from config (possibly a populated directory they just pointed at) while the running container still uses the old one — surprising data loss. The -y flag (#106) makes it unattended. Narrow trigger, but destructive.

Suggested fix

Resolve reset targets from .env (the live deployment), not a fresh config.json parse; or refuse to delete a dir lacking the expected stack-created layout (e.g. the stats/ subtree). At minimum print the absolute paths and require they match .env.

Related

Touches the same data-dir-resolution theme as #126; ties to assert_safe_dir hardening in #91.