node: an administrator judges the service's own state as the service, and an unreadable state directory refuses once with its true reason

[christianparpart]

Found on this machine's own installation, while redeploying it to master 4d6255fca: an administrator judging the healthy, running node's own registered line with --print-surfaces was refused.

What was wrong

• Measured with the installed 0.3.0-63-g4d6255fca, elevated, over the running service's state directory:
  • every state file is owned by NT SERVICE\FastCacheCompileNode;
  • the ownership check therefore refused to read them (neither the caller nor an administrative account), so the node read mode: none;
  • and it refused --raft-self with "the port comes from --listen-raft, which is also what turns consensus ON". But --listen-raft WAS on the line, and since Zero-config Windows office fleet #1600 the mode held in the state directory is what decides consensus.
• Consequences:
  • a confident wrong signal to the operator;
  • every future redeploy's judgement of the live line would be refused the same way;
  • the deeper remedy text told the operator to remove files merely because the node's own service owns them, which on a running node throws away its identity.

What changes

• One early refusal for an unreadable state directory, before any flag rule can blame --listen-raft, --discovery, --dashboard or the closed-consensus worker check. It names the true reason and a remedy that is true for that reason. It is refused by the step that failed:
  • a listing or access-list query that failed exits 1, which the supervisor retries as before;
  • a file another account owns, or an unknown entry, exits 78 (--print-surfaces: 2).
• Owner ruling: an administrator judging, in a verb that writes nothing, counts files owned by the node's OWN per-service account (NT SERVICE\<--service-name>) as the node's own.
  • Only --print-surfaces trusts them. Which verbs write is a table column; --print-identity (which can mint), a foreground start and --install-service keep the strict owner set.
  • Only a per-service SID counts, compared as SIDs: --service-name="ALL SERVICES" (the group S-1-5-80-0) is refused, and an empty or unresolvable name trusts nothing.
  • --service-name comes from the command line only.
  • Stated blind spot: it fails OPEN only for an administrator who deliberately names ANOTHER service, and --print-surfaces writes nothing.
  • POSIX is unchanged, and the rule says what extending it would take.
• No remedy tells an operator to remove something because the node's own service account owns it. Removal is offered only for a planted file.

Verification

• WSL, whole binaries:

  • fastcache-compile-node-tests: 1452 cases, 1451 passed, 1 skipped;
  • FastCacheTest: 3218 cases, 3211 passed, 7 skipped.

• Neuters: each of the six new guards was neutered in turn, and only its own cases went red.

• Formatting and lint: the pinned clang-format and clang-tidy (22.1.8) are clean; a planted violation was caught. MSVC compiles the changed files clean with warnings as errors.

• A Windows test runs the production SID code (NT SERVICE\TrustedInstaller and a test file's owner).

• End to end on Windows, the branch built as cl-release 0.3.0-64-gd0bba3958, against the live node, whose service kept running:

  case	before (0.3.0-63)	after
  elevated --print-surfaces, live line	mode: none, rc 2, blames --listen-raft	mode: solitary, rc 0
  unelevated --print-surfaces, live line	(not measured)	rc 1, the true reason (cannot list the directory: access denied) and who can
  elevated FOREGROUND start over a copy of the service-owned state (owners and access lists kept)	(not measured)	refused, exit 78, nothing written, naming the owner and the safe remedy