[leongdl]

Fixes: no GitHub issue. Follow-up to #262.

What was the problem/requirement? (What/Why)

NamedPipeHelper.create_security_attributes() resolved the current user's SID with LookupAccountName("", getpass.getuser()). getpass.getuser() reads only the LOGNAME, USER, LNAME and USERNAME environment variables, and the lookup goes through LSA, which can fail with ERROR_NONE_MAPPED (1332).

A Windows integration build of deadline-cloud-for-blender, running as SYSTEM, failed 7 tests with (1332, 'LookupAccountName', 'No mapping between account names and security IDs was done.'). The error hit both the server path (create_named_pipe_server) and the client path (establish_named_pipe_connection), after the retry added in #262 (sleeps of 1 s and 2 s) ran out. The same commit passed on the builds before and after, so this is a transient host-state failure of the name lookup.

What was the solution? (How)

• Read the user SID from the process token: OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY) and GetTokenInformation(token, TokenUser)[0], closing the token in a finally. No name lookup is made, so 1332 cannot occur, and the SID no longer depends on environment variables. The fix: retry LookupAccountName with exponential backoff to prevent ERROR_NONE_MAPPED on fresh EC2 instances #262 retry and the getpass import are removed.
• The client no longer builds a DACL. CreateFile ignores the security descriptor when it opens an existing pipe and uses only bInheritHandle. The client passes SECURITY_ATTRIBUTES with no descriptor and bInheritHandle = True, which matches pywin32's SECURITY_ATTRIBUTES() default that it used before. Passing None would have made the handle non-inheritable.
• The server DACL is unchanged: GENERIC_READ|GENERIC_WRITE allowed to the user SID, GENERIC_ALL denied to NETWORK (S-1-5-2).

What is the impact of this change?

Windows named pipe servers and clients no longer fail when LSA cannot map the environment's user name. The pipe is granted to the account the process runs as. Where the environment named a different account, the old code granted the pipe to that named account instead.

How was this change tested?

• Unit tests: the token SID ends up in the DACL, LookupAccountName is not called when the environment names an unmapped user, the token is closed when GetTokenInformation raises, and the client passes no descriptor, an inheritable handle and OPEN_EXISTING. The three tests that pinned the removed lookup and retry are replaced.
• Windows integration test test_pipe_security_does_not_depend_on_user_name: sets LOGNAME, USER, LNAME and USERNAME to a non-existent account, asserts that LookupAccountName raises 1332 for that name, runs a real pipe round-trip and reads the pipe's DACL back with GetSecurityInfo. It runs for server and client, for the client only, and with the normal environment as a control. It is collected by the existing hatch run test step in the Windows job of code_quality.yml.
• On macOS: hatch run lint, hatch run mypy --platform win32 src test and hatch run test pass (482 passed, 31 skipped, 93.39% coverage). The Windows tests have not run on real Windows before this PR; this PR's Windows CI is their first run.
• Mutation check: putting back the name lookup, and separately putting back the client DACL, each fails the new tests. That was run against a simulated pywin32, not real Windows.

Was this change documented?

Docstrings and comments in named_pipe_helper.py are updated. No user-facing docs change.

Is this a breaking change?

No. No public interface changes.

Does this change impact security?

Yes, narrowly. It changes how the pipe DACL picks its user: the process's own account instead of the account named by the environment. That matches the documented intent (only the current user, network logons denied). The NETWORK deny ACE is unchanged and no new principal gains access. Maintainers may want to add the "security" label.

Known gaps, not in this PR:

• _secure_open.py resolves its SID with the same LookupAccountName pattern.
• The assert in test_fail_to_connect_to_named_pipe_with_different_user sits inside pytest.raises, so it never runs.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Claude review · advisory

Reviewed 566de5c (changes since 40db387): 0 new, 0 resolved.

Open: 0 blocking · 0 should-fix · 0 nit. ✅ Nothing blocking.

_{Fix or reply to each thread; the next revision's review re-checks open threads and resolves those it agrees are handled. Resolving a thread yourself also closes it. Later revisions review only what changed.}