Install and upgrade lock the Darling install folder, so an ordinary local user can no longer replace the service's binaries (#4034)

[erikdarlingdata]

Closes #4034.

Why

The README's install location, C:\PerformanceMonitorDarling, is a folder made directly under C:\, and such a folder inherits NT AUTHORITY\Authenticated Users:(M) from the volume root (checked with icacls C:\). Any local user could replace PerformanceMonitor.Darling.Service.exe, a DLL, or pg-runtime\pgsql\bin\postgres.exe, and their code would run as the service account at the next start. install-darling.ps1 hardened only the secret files. Found by the round-1 security review of #4031, outside that PR's diff.

What changes

• Lock-DarlingInstallTree, byte-identical in both scripts:
  • Stops the root inheriting from the volume root (icacls /inheritance:d, which keeps SYSTEM and Administrators full control as explicit ACEs).
  • Removes Authenticated Users, Users, Everyone and INTERACTIVE.
  • Grants back Users read and execute and the service account Modify. The service held Modify before through Authenticated Users, and it still needs it to extract pg-runtime into the tree.
  • Then reads every directory and file back and returns anything a broad principal can still write.
• Where it runs: install-darling.ps1 step 4b2, after the secret files are hardened and before the first start. upgrade-darling.ps1 runs it after the overlay copy, before the service starts, so every existing install is closed at its next upgrade.
• Why icacls: Set-Acl on an object Get-Acl read also writes the SACL, which needs SeSecurityPrivilege. icacls touches only the DACL, and it's the same set of commands the warning prints for fixing it by hand.
• Unchanged: protected files such as darling.json and the credential blobs keep their own DACLs. Logs and the managed PostgreSQL data live under ProgramData and are outside this tree.
• What a folder lock can't fix: a child that grants a broad principal write explicitly, behind its own protection, keeps that grant. It is named in the warning with its icacls /reset fix.
• README: the install section says the folder is locked, and that upgrades lock older installs.

Test plan

• TheInstallTreeLock_ShipsIdenticallyInTheInstallAndUpgradeScripts: the two copies, comment included, are byte-identical.
• TheInstallTreeLock_ClosesTheInheritedGrant_KeepsProtectedFiles_AndReportsWhatItCannotClose runs the shipped function under Windows PowerShell 5.1, against a tree planted directly under the system drive root that inherits Authenticated Users:(M). Afterwards:
  • the root is protected with no Authenticated Users;
  • Users have ReadAndExecute;
  • the service has Modify, which postgres.exe inherits;
  • darling.json keeps its protected DACL and INTERACTIVE read;
  • a child with its own broad grant is reported.
• Red-watch: with the strip step removed from the shipped script, the functional test fails.
• Every class that reads either script passes, 176/176: InstallLocation, DeployStaleFile, DeployRollbackRetention, FileSecurity, FirewallCheck, HardenFilesVerb, RuntimePreflight and ServiceInstallLocation. Build: 0 warnings.
• Both scripts parse under Windows PowerShell 5.1, and stay ASCII with CRLF. The upgrade warning's format string was executed once with stub values.
• An end-to-end install and upgrade on a real box (DARLING01), with the service starting and extracting pg-runtime under the lock.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv