feat: machine-wide control-token state dir + dig-node open handler (#501, #389)

[MichaelTaylor3d]

TLDR

Fixes #501 (a service-installed node's control token is unreachable by the operator CLI) and implements #389 (dig-node open as the OS chia:// / urn:dig:chia: scheme handler). Additive + back-compat. All gates green locally (fmt, clippy, 115 lib + 45 server + 8 content_serve + 5 drift tests).

Deliverable A — #501: machine-wide daemon state dir

On a real install the node runs as a service under a DIFFERENT OS account (Windows LocalSystem / a root daemon) than the operator's interactive CLI. The control token lived at <config_dir>/control-token, resolved from the running process identity (%LOCALAPPDATA% / $HOME), so the service wrote it under C:\Windows\System32\config\systemprofile\... while dig-node pair (as the user) resolved a different path — and minted a phantom token the node never trusts → every control.* failed -32030.

Fix: a new state::state_dir() — machine-wide + identity-INDEPENDENT — holds ONLY the control token + paired-tokens.json. The bulk per-user .dig cache + config.json stay exactly as-is (#96, untouched).

• Locations: Windows %PROGRAMDATA%\DigNode; Linux /var/lib/dig-node (→ /etc/dig-node); macOS /Library/Application Support/DigNode. Env override DIG_NODE_STATE_DIR. Back-compat: a non-service dev dig-node run with no machine dir falls back to the legacy per-user path — nothing that worked before breaks.
• Decoupled control_token_path() from config_path(); ControlCtx/AppState carry a state_dir; all pairing/paired-token call sites use it.
• Service self-identifies via DIG_NODE_RUN_CONTEXT=service (set by install into the service env + by the Windows SCM entrypoint); only a service bootstraps the machine dir, never a bare CLI.
• dig-node install pre-creates the dir as the interactive user so its ACL grants that user access to the token the LocalSystem service later writes — the crux of the Windows fix.
• dig-node pair now reads the token READ-ONLY (load_token_readonly) — never mints a phantom (the root of the original bug) — and the -32030 error + CLI print the PRECISE service-vs-user remedy (exact path, needs elevation / install-user read ACL) instead of a generic hint.

Security / ACL model (the crux)

The control token grants full local node control, so a machine-wide file must NOT be all-users-readable (local priv-esc). Created dir/token get a restrictive ACL, applied only on fresh create so a later SYSTEM/root run cannot clobber the installer's grant:

• Unix: dir 0700, file 0600 (never 0644). CI-gated assertion (created_token_file_is_not_world_or_group_readable).
• Windows: inheritance removed (icacls /inheritance:r) + inheritable full to EXACTLY SYSTEM + Administrators + the creating user, nobody else; the token file inherits the dir ACL (restrict_file is a no-op on Windows by design, so a SYSTEM re-run can't strip the install-user's inherited grant).
• Creator gets full (not read-only): the minting process must write the token; an elevated installer retains read. The security-critical property — every OTHER local user denied — holds either way. (I corrected the prior draft's read-only grant, which made fresh-create fail with Access Denied; verified via the icacls path on Windows + the Unix 0600 test.)
• Threat model + ACL documented in SPEC §7.3a.

Deliverable B — #389: dig-node open <link>

The OS handler target (dig-node open "%1") for chia:// + urn:dig:chia:. Treats %1 as UNTRUSTED (a hostile page can invoke a registered scheme):

• Strict validation: only chia:// / urn:dig:chia: (case-insensitive); store ref must be canonical 64-hex; rejects file:/javascript:/data:/http(s):, shell metacharacters, control chars, whitespace, .. traversal → exits USAGE (2), launches nothing.
• No shell, ever: the resolved URL is launched with the URL as a SINGLE non-shell argv entry (Windows rundll32 url.dll,FileProtocolHandler, Linux xdg-open, macOS open), behind an injectable UrlLauncher trait so tests assert the exact URL without spawning a browser.
• Behavior: opens the DEFAULT browser at the node's local serve URL http://<host>:<port>/s/<storeId>[:<root>]/<path> (#289 route; default localhost:9778). It does NOT re-open chia:// at the OS level (dig-node IS the OS handler → would recurse) and never opens a dig-node GUI. --json → {opened,url,store_id,root,path}.

Blast radius (gitnexus impact on control_token_path, upstream)

HIGH: direct caller load_or_create_token → pair::run + server::build_state → serve_with_shutdown. The signature change (control_token_path() now arg-less) has ONE direct caller (load_or_create_token, updated); pair switched to read-only load; build_state resolves + stores state_dir. All pairing call sites (control.rs dispatch + 4 in server.rs) migrated config_path → state_dir. Integration harnesses set DIG_NODE_STATE_DIR for hermeticity. No consumers outside this crate touch these symbols.

Version

0.26.0 → 0.27.0 — minor (feat; additive + back-compat: new state_dir, new open subcommand, legacy per-user fallback preserved).

Cross-repo (orchestrator owns SYSTEM.md)

Flagging for SYSTEM.md: the control-token location is now the machine-wide state dir (a shared cross-repo fact — the DIG Browser "My Node" UI + any local controller must read <state_dir>/control-token, not <config_dir>), and the OS chia:///urn:dig:chia: handler contract (dig-node open "%1" → local serve URL) — the dig-installer registers these handlers. Please add both to SYSTEM.md's cross-repo map.

Do NOT merge yet

Per the task: orchestrator adversarially verifies the token/ACL model + the open scheme-handler surface first.

🤖 Generated with Claude Code