Skip to content

test: assert the Windows credentials-directory ACL - #70

Merged
StuartMeeks merged 1 commit into
mainfrom
fix/47-windows-acl-test
Aug 25, 2026
Merged

test: assert the Windows credentials-directory ACL#70
StuartMeeks merged 1 commit into
mainfrom
fix/47-windows-acl-test

Conversation

@StuartMeeks

Copy link
Copy Markdown
Owner

Fixes #47.

The gap

CredentialsDirectoryTests skipped its Windows case with:

return; // Unix-only: Windows uses ACLs, verified via the file-perm integration path.

Grepping the whole test project for GetAccessControl, FileSystemAccessRule and DirectorySecurity returned zero hits. No such path existed. The comment was worse than no comment — it told a reader coverage existed.

CredentialsDirectory.CreateWithWindowsAcl — inheritance disabled, explicit FullControl for the current user and SYSTEM only — was therefore asserted nowhere, while being the stated security boundary for LocalFileCredentialEncryption and one of the two reasons CLAUDE.md gives for keeping the Windows CI leg.

What it asserts

  • AreAccessRulesProtected — inheritance is off, so %USERPROFILE% ACEs do not reach here.
  • The rule set is exactly the current user and SYSTEM, compared as a whole set rather than checking our rule is present. That is what catches an extra grant, which is the regression that matters.
  • Every rule is Allow + FullControl.

One deliberate inconsistency

The Unix test keeps its early-return guard instead of moving to Assert.SkipWhen like the new Windows test. That branch is what lets the analyzer narrow the platform for the File.GetUnixFileMode calls below it — converting it trips CA1416, which TreatWarningsAsErrors turns into a build failure. It is commented in place so it does not read as an oversight.

Verification

Build clean, 404 tests (350 passed, 54 skipped), up from 402. The new test is skipped here and runs on CI's Windows leg — which is exactly the leg that existed for this and was not using it.

🤖 Generated with Claude Code

CredentialsDirectoryTests skipped its Windows case with the comment "Unix-only:
Windows uses ACLs, verified via the file-perm integration path." No such path
existed: grepping the test project for GetAccessControl, FileSystemAccessRule
and DirectorySecurity returned zero hits. The comment was worse than none -- it
told a reader coverage existed.

So CredentialsDirectory.CreateWithWindowsAcl was asserted nowhere, and a
regression in it -- wrong SID, inheritance left enabled, an ACE dropped -- would
ship green on all three platforms. ACL hardening is one of the two reasons
CLAUDE.md gives for keeping the Windows CI leg, and it is the stated security
boundary for LocalFileCredentialEncryption.

The new test asserts AreAccessRulesProtected, and that the rule set is exactly
the current user and SYSTEM with FullControl/Allow. Asserting the whole set,
rather than that our rule is present, is what catches an extra grant.

The Unix test keeps its early-return guard rather than moving to
Assert.SkipWhen: that branch is what lets the analyzer narrow the platform for
the File.GetUnixFileMode calls below it (CA1416). Noted in place so the
inconsistency with the new test does not read as an oversight.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@StuartMeeks
StuartMeeks merged commit 184f3e6 into main Aug 25, 2026
9 checks passed
@StuartMeeks
StuartMeeks deleted the fix/47-windows-acl-test branch August 25, 2026 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows ACL hardening is verified by no test, behind a comment claiming otherwise

1 participant