[GH-ISSUE #5225] [Windows x64] rea inspect --provider ghidra fails snapshot admission with Win32 5 (EACCES) in an AppContainer process; succeeds from an ordinary shell #3199

New issue

Open

opened 2026-10-31 00:37:46 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:37:46 +00:00

Owner

Originally created by @litigationsisonkeattorneys-gif on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5225

Summary

rea inspect --provider ghidra fails during Windows target snapshot admission with Win32 error 5 (EACCES) when run from the Codex AppContainer runner. The same command on the same target succeeds from an ordinary Medium-integrity, non-AppContainer PowerShell window.

Reproduction

In the Codex runner PowerShell invocation, immediately before the inspection, a read-only query of the parent PowerShell token reported IsAppContainer=1, RestrictedSidCount=0, Low integrity, and TEMP beneath Packages\sandbox.<redacted>\AC\Temp. In that invocation:

rea --format json --full-output inspect C:\Windows\System32\where.exe --provider ghidra

Observed result: exit 1; ok=false; failure_kind=start; failure_message=Ghidra target snapshot failed admission; Win32 5 / EACCES; REA duration about 0.8 seconds. The denied file was the private snapshot copy (target-<hash>.exe) beneath a rea-ghidra-* runtime root in the caller's AC\Temp. No rea-* runtime directory remained afterward.

In the same PowerShell invocation, rea doctor --provider ghidra ran immediately before inspect and returned native_authority=true, exit 0. The token query was on the parent PowerShell; doctor and inspect ran as separate child processes, whose tokens were not queried independently.

Control: the same command from an ordinary PowerShell window (TokenIsAppContainer=0, Medium integrity, restricted SID count 0) succeeds: exit 0, ok=true, 198 procedures, about 42 seconds (41.8 seconds reported by REA; 43.09 seconds elapsed).

Original v80 observation

An earlier v80 Ghidra inspection failed at snapshot admission with the same Win32 5 / EACCES outcome, with its runtime path beneath Packages\sandbox.<redacted>\AC\Temp. That failing process's token was not probed, and its sandbox package identifier differed from the later where.exe reproduction. These runs should not be treated as the same sandbox instance.

Access-denial mechanism reproduced without REA

In the Codex AppContainer runner, a scratch directory with a protected DACL granting only the current user and SYSTEM allowed directory creation but denied file creation inside it. Adding an ALL APPLICATION PACKAGES ACE to an otherwise similar directory allowed the file create. This reproduces a mechanism consistent with the reported denial; REA's actual runtime DACL on this host was not observed.

Request

Does the Windows Ghidra provider support AppContainer callers? If so, please document or implement least-privilege access for the caller's own package SID. If not, please document that AppContainer callers are unsupported and have doctor detect TokenIsAppContainer. Please avoid recommending ALL APPLICATION PACKAGES as the fix.

References

Originally created by @litigationsisonkeattorneys-gif on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5225 ## Summary `rea inspect --provider ghidra` fails during Windows target snapshot admission with Win32 error 5 (`EACCES`) when run from the Codex AppContainer runner. The same command on the same target succeeds from an ordinary Medium-integrity, non-AppContainer PowerShell window. ## Reproduction In the Codex runner PowerShell invocation, immediately before the inspection, a read-only query of the parent PowerShell token reported `IsAppContainer=1`, `RestrictedSidCount=0`, Low integrity, and TEMP beneath `Packages\sandbox.<redacted>\AC\Temp`. In that invocation: ```powershell rea --format json --full-output inspect C:\Windows\System32\where.exe --provider ghidra ``` Observed result: exit 1; `ok=false`; `failure_kind=start`; `failure_message=Ghidra target snapshot failed admission`; Win32 5 / `EACCES`; REA duration about 0.8 seconds. The denied file was the private snapshot copy (`target-<hash>.exe`) beneath a `rea-ghidra-*` runtime root in the caller's `AC\Temp`. No `rea-*` runtime directory remained afterward. In the same PowerShell invocation, `rea doctor --provider ghidra` ran immediately before `inspect` and returned `native_authority=true`, exit 0. The token query was on the parent PowerShell; `doctor` and `inspect` ran as separate child processes, whose tokens were not queried independently. Control: the same command from an ordinary PowerShell window (`TokenIsAppContainer=0`, Medium integrity, restricted SID count 0) succeeds: exit 0, `ok=true`, 198 procedures, about 42 seconds (41.8 seconds reported by REA; 43.09 seconds elapsed). ## Original v80 observation An earlier v80 Ghidra inspection failed at snapshot admission with the same Win32 5 / `EACCES` outcome, with its runtime path beneath `Packages\sandbox.<redacted>\AC\Temp`. That failing process's token was not probed, and its sandbox package identifier differed from the later `where.exe` reproduction. These runs should not be treated as the same sandbox instance. ## Access-denial mechanism reproduced without REA In the Codex AppContainer runner, a scratch directory with a protected DACL granting only the current user and SYSTEM allowed directory creation but denied file creation inside it. Adding an `ALL APPLICATION PACKAGES` ACE to an otherwise similar directory allowed the file create. This reproduces a mechanism consistent with the reported denial; REA's actual runtime DACL on this host was not observed. ## Request Does the Windows Ghidra provider support AppContainer callers? If so, please document or implement least-privilege access for the caller's own package SID. If not, please document that AppContainer callers are unsupported and have `doctor` detect `TokenIsAppContainer`. Please avoid recommending `ALL APPLICATION PACKAGES` as the fix. ## References - [Microsoft: Implementing an AppContainer](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer) - [Microsoft: TOKEN_INFORMATION_CLASS](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ne-winnt-token_information_class)

bsakaguchi commented

2026-10-31 00:37:47 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 19, 2026):

Cross-referencing with sibling Windows native permission report #5237 ([Windows native] Private DACL contains unexpected trustees (Win32 5) blocks Android inspection before JADX) and parent handle authority issue #289. In restricted Windows contexts (AppContainer, sandboxed tokens, non-standard local trustees), the native security descriptor construction in native/windows/src/filesystem.cc fails snapshot admission with Win32 5 (EACCES).

Consolidated under Cluster Y (Windows Native Handle Authority, Private DACL & AppContainer Admission Failures) in tracker #4330.

@matbrgz commented on GitHub (Oct 19, 2026): Cross-referencing with sibling Windows native permission report #5237 (`[Windows native] Private DACL contains unexpected trustees (Win32 5) blocks Android inspection before JADX`) and parent handle authority issue #289. In restricted Windows contexts (AppContainer, sandboxed tokens, non-standard local trustees), the native security descriptor construction in `native/windows/src/filesystem.cc` fails snapshot admission with Win32 5 (EACCES). Consolidated under **Cluster Y (Windows Native Handle Authority, Private DACL & AppContainer Admission Failures)** in tracker #4330.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3199

No description provided.

Rows
Columns