Repository navigation
Fix restricted Windows token access from PowerShell - #185
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Windows startup from an elevated PowerShell context could fail with
initdb: could not open process token: error code 5. Restricted children inherited permissions that depended on the disabled Administrators SID. The new restricted token and its default objects now grant access to the actual user and SYSTEM, allowing children to reopen their own tokens. Administrator and power-user groups remain deny-only, privileges stay restricted, and existing caller tokens and directory ACLs are unchanged.Windows CI now exercises nested token access, Go/CLI lifecycles under Go 1.26.9 and 1.27.2 directly from PowerShell, and the detached hidden Node launch used by the wrapper. The PowerShell checks build normal CLI executables, while the existing instrumented native suites continue to supply coverage. Caller-owned Windows directory-access requirements are documented.
Adds a public post-publication workflow and a local reproduction command for actual Go module/CLI consumers: six native platforms and x64/ARM64 Alpine, both supported Go versions, exact source identity, checksums, build attestations, fresh downloads, SQL, offline reuse and cleanup. Evidence stays in the public product repository; no private validation repository is needed.
Validation at
e9493a7870f163c4b84dcbb225a75556e703aab0: