fix(policy): survive atomic replacement of resolv.conf; report stale …

[maufl]

Linked Issue

References #986 — a partial fix by design (diagnostics plus one built-in policy instance, per the disclosure comment on the issue), so intentionally not Closes.

Summary

Landlock rules bind to the inode open at ruleset build, so a file-level grant goes stale when the file is atomically replaced (write-temp + rename(2)). This PR:

1. Policy (data/policy.json): system_read_linux_core additionally grants the directory /run/systemd/resolve (read). Its /etc/resolv.conf file grant canonicalizes to stub-resolv.conf, which systemd-resolved replaces on any resolver-config change, breaking DNS for the rest of the session. Directory rules cover children created later, so they survive; non-systemd systems skip the missing path.
2. Diagnostics: the capability state file records (dev, ino) per file grant at sandbox start (Linux only; optional fields, compatible both ways). nono why re-stats the granted path and reports DENIED / stale_file_grant with grant-time vs. current inode and a restart hint — or ALLOWED with a warning when a directory grant still covers the path. Non---self queries load the state leniently (unreadable state ⇒ no hints, never an error); --self stays strict.
3. Docs: troubleshooting entry + Landlock-internals note.

DENIED
  Reason: stale_file_grant
  Details: The sandbox granted this file, but the file at ... was replaced
  after sandbox start (inode 39:175234 when the sandbox started, 39:175245
  now). Landlock rules bind to the inode, not the path, ... Restart the
  sandbox to re-apply the grant to the current file.

Deliberately not done: Landlock has no path-based rules, so the only way a file grant can survive replacement is granting its parent directory. We did not apply that automatically to all file grants — it silently widens each to its whole directory, a posture change maintainers should make explicitly, per grant (as done here). The issue's repro still reproduces for user/profile file grants, now diagnosable. Other rename-prone builtin file grants (/etc/ld.so.cache, /etc/hosts, …) remain — their parent /etc is too broad. /run/systemd/resolve is systemd-specific in-tree policy; per NOGENT.md a nono package may be the longer-term home — guidance welcome.

Agent Disclosure

• Agent-assisted contribution (Claude Fable 5 via Claude Code), directed and reviewed by @maufl; intent disclosed on filesystem.read_file grants become stale when target is replaced via atomic rename (Linux/Landlock) #986 before opening this PR.
• Consulted: AGENTS.md, NOGENT.md, sandbox/linux.rs (PathFd inode binding), capability.rs (grant-time canonicalization), policy.rs, sandbox_state.rs, why_runtime.rs, query_ext.rs, the profile authoring guide, and this template. All code newly written; nothing reused or adapted.
• Confirmed compliant with repository coding and security requirements: NonoError propagation, no unwrap/expect in production code, paths canonicalized, fail-closed behavior preserved (the lenient loader affects diagnostics only, never enforcement).

Test Plan

• New unit tests: staleness detection (fresh / in-place / replaced / removed), both why verdicts, pass-through, inode recording, legacy-state compatibility, lenient-loader failure modes.
• make check, make test, cargo audit, make lint-aliases, make lint-docs pass locally (remaining failures are pre-existing PTY/AF_UNIX tests needing permissions the sandboxed dev env lacks, all in untouched files).
• Verified end-to-end on Arch/zen (Landlock ABI v6): resolv.conf reads survive stub replacement under the new grant; the output above is from a live session; non---self why still answers with an unreadable state file.

Checklist

• An issue exists and is linked above
• All commits are signed-off, using DCO
• All new code follows the project's coding standards (CLAUDE.md) and is covered by tests
• Public-facing changes are paired with documentation updates
• Release note has been added to CHANGELOG.md if needed (generated via git-cliff from conventional commits)

Agent Compliance Check (Required for AI/Automated PRs)

• I am not prohibited from contributing under this policy
• An issue already exists
• I disclosed that I am an agent in the issue discussion
• I described my intent and approach in the issue discussion
• I reviewed repository coding and security rules for the affected area
• I provided required attribution for reused or adapted code
• I did not use forbidden patterns such as unwrap/expect
• I used NonoError where required
• I validated and canonicalized all relevant paths
• This PR matches the approved or disclosed issue scope

[github-actions]

PR Review Summary

Size

Metric	Value
Lines added	+602
Lines removed	-12
Total changed	614
Classification	Large (> 300 lines)

Affected crates

• crates/nono-cli — CLI changes. Verify argument parsing, flag documentation, and UX behaviour across supported platforms.

Blast radius — Moderate

This PR touches: source code,configuration / policy files

---

_{Updated automatically on each push to this PR.}

[nogent-nolabs-ai]

nogent code review

No blocking issues found; 0 findings.

Findings: none flagged in scope.

_{Automated code + security review. CI already covers clippy, rustfmt, tests, cargo-audit and commit-lint.}

[lukehinds]

Thanks @maufl , I am good with the /run/systemd/resolve grant, there is nothing private there , the alternative (broken DNS on every resolver-config change) is much worse. approved