0c574e0f49
A directory created directly under C:\ inherits the drive root's DACL, and the default carries an inherit-only Modify grant for Authenticated Users. So C:\shopdb-flask, C:\Python314 and C:\MySQL84 were writable by every logged-on user on the server. That is a local privilege escalation here specifically, because two things this installer puts inside those roots are executed by someone else: shopdb-admin.ps1 self-elevates with -Verb RunAs, and instance\config.py is loaded unconditionally by the app through from_pyfile. Replace either, wait for an administrator or the app pool to run it, and the code runs as them. Hardening is applied at creation and RE-APPLIED on every run, so an upgrade over an installation that predates this repairs the ACL rather than leaving the hole in place. The MySQL data directory is locked down too: it holds the users table and its password hashes, and it inherits ProgramData's read-for-Users. The app pool is granted RX on the Python root alongside the app root. A venv's python.exe is a copy but the DLL and the standard library are still read from the base install, so without that grant the site 500s on every request once the roots stop inheriting. A Python installation this installer did not create is reported, not seized: something else may depend on the ACL it has. Verified as SYSTEM in the Windows 11 VM against the functions as shipped (extracted by AST, not retyped): the inherited ACL really does grant non-admins write; after hardening only Administrators and SYSTEM remain; a service identity granted afterwards keeps access and later-created files inherit it; re-running is a no-op; a missing path is silently skipped. 14 checks, all passing.
149 KiB
149 KiB