Lock down backup directory ACLs, and let the uninstaller reach IIS
Two findings from the installer review, both of which fail silently. Database dumps were readable by every authenticated user. A directory created under ProgramData inherits BUILTIN\Users:(I)(OI)(CI)(RX), and a dump contains every row including the users table and its password hashes. The installer applied an owner-only ACL, but only in the branch that CREATED the directory, so a directory created first by the console (shopdb-admin.ps1 backup) kept the inherited permissions and the installer could never repair it. The ACL is now re-applied on every run rather than only on creation, and the grants are made inheritable with (OI)(CI) so dumps written into the directory later are covered too. shopdb-admin.ps1 applies the same hardening for the default location, and for an operator-named path says the dump holds password hashes rather than silently rewriting the ACL of a directory that is theirs. Verified on Windows: before, the directory carried BUILTIN\Users:(I)(OI)(CI) (RX); after, only SYSTEM and Administrators, and a file created inside inherits exactly those two. Without (OI)(CI) that file would not have been covered. The uninstaller could not remove anything in IIS. [UninstallRun] launched a bare "powershell.exe", and the Inno uninstaller is a 32-bit process, so WOW64 resolved it to the 32-bit PowerShell, which cannot see the IIS provider. The site, application pool and application survived, pointing at a directory that HAD been deleted, while Windows reported a clean uninstall. It now uses the same Sysnative path as the [Run] entry, which was the last unshielded launch site in the file.
This commit is contained in:
@@ -1206,6 +1206,12 @@ end;
|
||||
; Delegate to the same tested script rather than duplicating removal logic here.
|
||||
; It removes the site, app pool, firewall rule and application directory, and
|
||||
; deliberately does NOT drop the database or uninstall MySQL.
|
||||
Filename: "powershell.exe"; \
|
||||
;
|
||||
; Sysnative, for the same reason as the [Run] entry above: the uninstaller is a
|
||||
; 32-bit process, so a bare "powershell.exe" is resolved through WOW64 to the
|
||||
; 32-bit PowerShell, which cannot see the IIS provider at all. Removal then
|
||||
; skipped the site, application pool and application - leaving them pointing at
|
||||
; a directory it HAD deleted - while Windows reported a clean uninstall.
|
||||
Filename: "{win}\Sysnative\WindowsPowerShell\v1.0\powershell.exe"; \
|
||||
Parameters: "-NoProfile -ExecutionPolicy Bypass -File ""{app}\shopdb-install.ps1"" -Stage uninstall -BundleRoot ""{app}"" -AppRoot ""{app}"" -OnFailure never"; \
|
||||
RunOnceId: "ShopDBFlaskUninstall"; Flags: waituntilterminated runhidden
|
||||
|
||||
Reference in New Issue
Block a user