EdnunpandClaude Fable 5
e0dc2fec94
Root cause found while REPRODUCING the suspected wrong-owner bug in a gate test (the repro failed in a way the theory couldn't explain, and the empirical icacls run showed why): the 5.6 hardening's /T sweep applied (OI)(CI) grants to FILES, where such ACEs are inherit-only — they grant the file itself NOTHING. Every file existing at harden time was left with /inheritance:r + inherit-only ACEs = an effectively EMPTY ACL: unreadable/unwritable by the user, admins, even SYSTEM. That is the Jonathan report (2026-08-06) end to end: profile save "access denied" even elevated, logs unreadable in Notepad, his own icacls /T "fix" adding useless inherit-only ACEs (137 processed, nothing healed), new files fine (echo test), and the service failing to start (SYSTEM can't read a wedged profile). The fix, in layers: - BuildServiceDirAclArgs no longer sweeps /T: the lockdown applies to the FOLDER only. Existing children are rebuilt by a new /reset pass (BuildResetChildrenArgs) as purely- inherited from the hardened folder ACL — real file access again, stale/planted explicit ACEs removed, and it HEALS files wedged by 5.6. Regression-pinned in the gate (the folder args must never contain /T again). - Second bug fixed in the same area: the elevated helper recorded ITS OWN token as the "installing user" — under over-the-shoulder elevation that's the separate admin account whose password was typed, not the person at the keyboard. Elevated verbs now carry --as-user <SID> from the non-elevated app (validated: real user SIDs only — service identities and builtin groups rejected) and install/repair re-record it, so a stale wrong owner can't persist through reinstalls or self-update re-hardens. - Self-heal everywhere: new --repair-service-access verb (re-record owner + re-harden); "Repair service folder access" in the Service menu; a startup write-probe that offers the repair when the folder is broken (settled startup sequence, ForegroundDialog, skipped on --silent); the profile-save UnauthorizedAccessException catch offers it at the exact wall users hit; and the service self-update's existing re-harden now runs the FIXED sequence, so wedged fleet machines heal automatically when 5.8 rolls out — no user action needed. - Logs readable again: Users get read-only on service\logs (inheritable, no /T needed — propagation covers existing files) and on service-events.log. The profile stays locked (it holds the obfuscated password). GrantUsersWriteToBin deleted — the folder ACL's inherited user-Modify covers bin, and the reset wiped its explicit grants anyway. - DoStart/DoStop no longer swallow the reason: exception recorded to service events, and distinct exit codes (6 timeout, 7 SCM refused, 9 repair-didn't-stick) let the dialog say what happened instead of the bare "(code 1)" that cost this diagnosis a day. Gate: new "Service folder repair" step reproduces BOTH bugs for real in a scratch folder — wedges a file with the exact 5.6 spec (proves reads genuinely die), locks the folder to the wrong owner, asserts the app's probe reports broken, runs the exact shipped repair sequence (ApplyServiceDirAcl), and asserts folder writable + wedged file readable again. Plus a SID pass-through step (validation, parse, arg-building, logs-grant shape). 72/72 + relay 7. Docs: Service-menu repair item + troubleshooting entry in readme; About + RELEASE_NOTES rewritten for 5.8; MANUAL regenerated. Version 5.8. NOT released — awaiting Ed's test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
RemSound v5.8
A repair for the lock-screen service's settings folder.
Some machines ended up with the service's settings folder locked so tightly that nothing could use it — saving the service profile failed with "access denied", the service's log files wouldn't open even in Notepad, and on some machines the service itself couldn't start. It came from a permissions bug in a recent release, and reinstalling didn't clear it.
This release fixes the cause and heals affected machines automatically:
- The service applies the fix on its own when it installs this update — for most people that's it, nothing to do.
- RemSound also checks the folder every time it starts, and offers a one-click repair if it finds a problem.
- And there's a "Repair service folder access" item in the Service menu you can run any time. One administrator prompt, and saving the service profile and reading the logs work again.
Also in this release
- The service's log files are readable from every account on the machine again, so you can always open them in Notepad if you need to look at one or send it in. (The service's settings stay protected as before.)
- If a service action fails, the message now says what actually went wrong instead of showing a bare error code, and the reason is recorded in the service's own log.
- The repair, and the folder protection itself, now always apply to the account that's actually using RemSound — even on PCs where a different account's password is typed at the administrator prompt.