Fix username check for env vars - #851
Tess Gauthier (tgauth) wants to merge 5 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the Windows process-spawn path to correctly detect the NT SERVICE\sshd virtual account (instead of treating any username starting with sshd as the service), and adds E2E coverage to prevent regressions for local users like sshd_user.
Changes:
- Replace username-prefix matching with token-based detection of the
NT SERVICE\sshdaccount when deciding whether to load a user environment block. - Add new Pester E2E tests validating user environment variables and PATH ordering for an
sshd_useraccount. - Extend test helper environment to provision and expose
SshdUserand its profile path.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| regress/pesterTests/UserEnvironment.Tests.ps1 | Adds new Pester E2E scenarios verifying user env vars and user PATH entries for sshd_user. |
| contrib/win32/win32compat/w32fd.c | Refactors the “sshd account” detection logic to use token SID lookup and skips env block only for the service virtual account. |
| contrib/win32/openssh/OpenSSHTestHelper.psm1 | Adds SshdUser test account and profile info to the shared test environment. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Please forgive me for the inaccuracy, I may be missing something as the context has faded from my mind over time. Filtering service account tokens by the "sshd" prefix - rather than strictly matching the single "sshd" string - is essential for supporting multi-instance OpenSSH environments and ensuring future-proof architecture. In advanced or enterprise Windows setups, administrators often register multiple SSH services on different ports or for isolation (e.g., sshd_2, sshd-prod), which automatically generate virtual accounts like NT SERVICE\sshd_2. |
|
Also, matching the NT SERVICE domain will fail if the service is configured to run under a custom local or domain account (e.g., sshd_svc_user). In this case, the domain will return the host or AD name instead of NT SERVICE, breaking the profile-loading logic for the legitimate service account. |
Thanks for pointing this out! May need to think more on ways to account for this but still ensure the profile is loaded for all valid session users |
The env-block skip for the sshd privsep worker was inferred from the token's resolved account name (is_sshd_service_token: name==sshd && domain==NT SERVICE). That misclassifies the actual worker token, which is the sshd_<pid> VIRTUAL USERS account (or an unresolvable SID once its LSA mapping is removed) in service mode, and the launching account in debug mode; a prefix form also wrongly captured real users like sshd_user / sshd-2. Decide instead in __posix_spawn_asuser using the identity string already in hand (strcmp(user, "sshd")), the same signal that already gates load_user_profile. Thread a load_user_env flag through posix_spawn_internal to spawn_child_internal and drop is_sshd_service_token. posix_spawn(p)_as_user always load the env block since their token is always a real interactive user (system/service clients are filtered out before the agent sets the token). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
5027697 to
0bbec5c
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
PR Summary
load_user_profile()and propagating it toCreateEnvironmentBlock()to ensure they are in syncsshd_user