Darling install tree: narrow the service account's Modify to pg-runtime and pg-runtime-prev (#4043 part 2)

[erikdarlingdata]

Split from #4043. Part 1 of that issue, the ACL check before the lock, ships in #4050. This is the part 2 residual (Low, defence in depth).

The gap

#4038's lock grants the Darling service account Modify on the whole install tree. Only pg-runtime\ and pg-runtime-prev\ need writes from the service. So a compromised service or postgres process can rewrite the service exe or a DLL and persist across restarts.

Fix

Grant the service account Read & Execute on the install root, and Modify only on pg-runtime\ and pg-runtime-prev\, created ahead of time. Do this in both install-darling.ps1 and the upgrade script, and pin the resulting ACEs in a test.

Write-site audit (static, done in #4050, not yet closed)

Path (under the install root)	Service writes?
pg-runtime\, pg-runtime-prev\, and the pg-runtime.sha256 / .stamp / .blocked stamp files	Yes. Confirmed, and scoped to those two folders (DarlingManagedPostgres, DarlingStoreUpgrade).
darling.json	No. Only the elevated installer (step 4b) and the --configure-network verb write it.
DarlingInstallLocation.Report	No. It reads only.
wwwroot (the web content root)	Believed read-only. Not verified.
The BringYourOwnDirectoryName folder beside darling.json (DarlingLogHashKeyFile.DirectoryFor)	Open. It is used only when postgres.managed = false and the service is not in a container (bring-your-own Postgres). The managed default resolves under %ProgramData%, outside the tree.

Resolve the open row before narrowing anything. Pick one:

• move that folder under %ProgramData%, and migrate an existing key;
• fold it into the Modify grant;
• show that nobody runs that combination on Windows.

Risk and verification

If a write site is missed, the service breaks at start, which is tier 1. So, before shipping:

• verify that wwwroot is read-only;
• run a real service install and upgrade on a disposable box, never on a monitored or dev-in-use host. Walk it through install, start, one collection cycle, restart, an upgrade that rescue-copies into pg-runtime-prev, and bring-your-own-Postgres mode if that mode keeps a write site in the tree.

Also exercise #4050 on the same box

#4050's check couldn't be tested where it was built. The box run should also cover:

• a real locked install re-run;
• a gMSA service account;
• a domain admin whose local-admin membership is nested;
• an install root on a second volume.

Confirm each passes or refuses as #4050's PR body says it should.

Done when

• The narrowed grant is in both scripts.
• A test pins the ACEs.
• The box run is recorded in the PR body.

[erikdarlingdata]

PR #4090 merged to dev as c51706c (2026-09-24 01:58Z), after its companion #4097 (e50a2aa). Together they deliver the install-tree lock narrowing:

• The install and upgrade scripts now give the Darling service account Read & Execute on the install folder, and Modify only on the bundled PostgreSQL runtime folders (pg-runtime, pg-runtime-prev) and, in bring-your-own-PostgreSQL mode, the key folder. Before, it had Modify on the whole install folder.
• Store upgrade keeps pg-runtime-prev in place instead of deleting and recreating it (prep for #4052) #4097 makes the service empty pg-runtime-prev in place instead of deleting and recreating it, which the narrower grant needs.

A two-phase box run on a Windows 11 VM passed (see the PR). This issue stays open: the second-volume, bring-your-own-PostgreSQL, gMSA and nested-admin cases still need a run on a real Windows machine after a nightly build.

[erikdarlingdata]

Closing: the work is merged. #4097 (the service keeps pg-runtime-prev in place) and #4090 (the service account gets RX on the install root and Modify only on pg-runtime\, pg-runtime-prev\ and the bring-your-own-PostgreSQL darling-keys\).

The box run on a standalone Windows 11 VM passed, and both phases are recorded on #4090:

• install, start, one collection cycle and a restart;
• an upgrade with a runtime rescue into pg-runtime-prev, and the V140 migration;
• a locked re-run of the installer.

The cases that VM can't test (a second-volume install root, bring-your-own-PostgreSQL mode, a gMSA service account, a nested domain admin) are the maintainer's own Windows-machine checks on a nightly that contains #4090. That nightly exists: dev at deacddd. Reopen this issue if any of them fails.