[GH-ISSUE #5237] [Windows native] Private DACL contains unexpected trustees (Win32 5) blocks Android inspection before JADX #3202

New issue

Open

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

bsakaguchi commented

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

Owner

Originally created by @newsdayads on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5237

Summary

On a Windows x64 host using the installed rea-agents 6.5.0, inspect-android-package fails before JADX runs because the bundled Windows native self-test reports:

code: capability_unavailable
category: unsupported_provider
provider_id: jadx
operation: inspect_android_package
REA Windows native self-test failed: Private DACL contains unexpected trustees [REDACTED_TEMP_PROBE] (Win32 5): Access is denied.

The input was a caller-owned APK with its digest verified before the attempt; no APK bytes or private paths are attached. The same error persisted when the process-local TEMP/TMP location was changed to a protected directory. No DACL or machine security settings were weakened. The executable's CLI help returns 0, but a real inspect-android-package call exits 1.

Source observation (not a host root-cause claim)

At tag rea-agents-6.5.0, native/windows/src/filesystem.cc checks in verifyPrivate:

require(acl->AceCount == 2, "Private DACL contains unexpected trustees", path, ERROR_ACCESS_DENIED);

Before that guard, GetSecurityInfo(... OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION) reads the descriptor. The same strict AceCount == 2 check is still in the rea-agents-6.7.0 source, though we have not reproduced this on 6.7.0.

Source:

Not established: the actual ACE count and trustee SIDs of the freshly created probe on this host, the exact installed native-addon digest/provenance, or the effective token context of the child process. We are not claiming a specific principal caused the mismatch.

Separate from existing Windows Win32 5 reports

#2196 and #1701: Delete owned object by handle failed is a different native failure, addressed separately.
#3111: confirms native self-test blocks APK inspection, but reports the delete-by-handle signature, not the strict DACL trustee count signature.
#5225: AppContainer snapshot admission is at another stage; we have not verified AppContainer on this host.

Request

Is this Private DACL contains unexpected trustees guard known to fail on legitimate Windows process token/NTFS combinations?
Can the native self-test expose sanitized, safe diagnostics for readback AceCount, current-user-vs-SYSTEM SID equality, and whether the created DACL is protected, without exposing private SIDs/paths or weakening the access policy?
Is there an officially supported remediation or Windows verifier for this exact signature? A fix should preserve least privilege, protected DACL, owner/readback-by-handle and fail-closed behavior.

We can provide a public fixture and sanitized metadata in follow-up where safe; we will not attach private APKs, host paths, secrets, or policy-bypassing workarounds.

Originally created by @newsdayads on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5237 ## Summary On a Windows x64 host using the installed **rea-agents 6.5.0**, `inspect-android-package` fails **before JADX runs** because the bundled Windows native self-test reports: ```text code: capability_unavailable category: unsupported_provider provider_id: jadx operation: inspect_android_package REA Windows native self-test failed: Private DACL contains unexpected trustees [REDACTED_TEMP_PROBE] (Win32 5): Access is denied. ``` The input was a caller-owned APK with its digest verified before the attempt; no APK bytes or private paths are attached. The same error persisted when the process-local TEMP/TMP location was changed to a protected directory. No DACL or machine security settings were weakened. The executable's CLI help returns 0, but a real `inspect-android-package` call exits 1. ## Source observation (not a host root-cause claim) At tag `rea-agents-6.5.0`, `native/windows/src/filesystem.cc` checks in `verifyPrivate`: ```cpp require(acl->AceCount == 2, "Private DACL contains unexpected trustees", path, ERROR_ACCESS_DENIED); ``` Before that guard, `GetSecurityInfo(... OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION)` reads the descriptor. The same strict `AceCount == 2` check is still in the `rea-agents-6.7.0` source, though **we have not reproduced this on 6.7.0**. Source: - https://github.com/morluto/rea/blob/rea-agents-6.5.0/native/windows/src/filesystem.cc - https://github.com/morluto/rea/blob/rea-agents-6.7.0/native/windows/src/filesystem.cc **Not established:** the actual ACE count and trustee SIDs of the freshly created probe on this host, the exact installed native-addon digest/provenance, or the effective token context of the child process. We are not claiming a specific principal caused the mismatch. ## Separate from existing Windows Win32 5 reports - #2196 and #1701: `Delete owned object by handle failed` is a different native failure, addressed separately. - #3111: confirms native self-test blocks APK inspection, but reports the **delete-by-handle** signature, not the strict **DACL trustee count** signature. - #5225: AppContainer snapshot admission is at another stage; we have not verified AppContainer on this host. ## Request 1. Is this `Private DACL contains unexpected trustees` guard known to fail on legitimate Windows process token/NTFS combinations? 2. Can the native self-test expose **sanitized, safe** diagnostics for readback `AceCount`, current-user-vs-SYSTEM SID equality, and whether the created DACL is protected, without exposing private SIDs/paths or weakening the access policy? 3. Is there an officially supported remediation or Windows verifier for this exact signature? A fix should preserve least privilege, protected DACL, owner/readback-by-handle and fail-closed behavior. We can provide a public fixture and sanitized metadata in follow-up where safe; we will not attach private APKs, host paths, secrets, or policy-bypassing workarounds.

bsakaguchi commented

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

Author

Owner

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

Additional source-path finding (read-only, not a host root-cause claim):

At tag rea-agents-6.5.0, native/windows/src/filesystem.cc:

Security() constructs two ACCESS_ALLOWED_ACE entries: TokenUser and WinLocalSystemSid (lines 127–155). It does not special-case equal SIDs.
verifyPrivate() first rejects acl->AceCount != 2 with "Private DACL contains unexpected trustees", before examining any SID (lines 212–224).
The subsequent SID dispatch checks current-user equality before an else if SYSTEM equality (lines 225–240). If TokenUser is LocalSystem and the readback really contains two same-SID ACEs, both entries take the user branch; system stays false, producing the different error "Private DACL must allow only current user and SYSTEM".

Consequently, merely observing a LocalSystem token or duplicate logical principals cannot explain the reported "unexpected trustees" signature. Under this source version, that signature requires a returned DACL ACE count other than two (or unverified installed-build/source drift). The reason for an ACE-count discrepancy on the affected host remains unknown.

Would a security-preserving Windows diagnostic expose only ace_count_readback, token_user_equals_system, SE_DACL_PROTECTED, plus the exact installed native-addon digest/version (without SIDs, private paths or object contents)? This would distinguish the count guard from later SID-dispatch errors without changing ACLs, disabling checks, or rerunning the same failing configuration.

Source: https://github.com/morluto/rea/blob/rea-agents-6.5.0/native/windows/src/filesystem.cc

No PC01 action, fresh native reproduction, or proposed security bypass is claimed.

@newsdayads commented on GitHub (Oct 19, 2026): Additional source-path finding (read-only, **not** a host root-cause claim): At tag `rea-agents-6.5.0`, `native/windows/src/filesystem.cc`: - `Security()` constructs two `ACCESS_ALLOWED_ACE` entries: `TokenUser` and `WinLocalSystemSid` (lines 127–155). It does not special-case equal SIDs. - `verifyPrivate()` first rejects `acl->AceCount != 2` with **"Private DACL contains unexpected trustees"**, before examining any SID (lines 212–224). - The subsequent SID dispatch checks current-user equality before an `else if` SYSTEM equality (lines 225–240). **If** `TokenUser` is LocalSystem and the readback really contains two same-SID ACEs, both entries take the user branch; `system` stays false, producing the **different** error "Private DACL must allow only current user and SYSTEM". Consequently, merely observing a LocalSystem token or duplicate logical principals cannot explain the *reported* "unexpected trustees" signature. Under this source version, that signature requires a returned DACL ACE count other than two (or unverified installed-build/source drift). The *reason* for an ACE-count discrepancy on the affected host remains unknown. Would a security-preserving Windows diagnostic expose only `ace_count_readback`, `token_user_equals_system`, `SE_DACL_PROTECTED`, plus the **exact installed native-addon digest/version** (without SIDs, private paths or object contents)? This would distinguish the count guard from later SID-dispatch errors without changing ACLs, disabling checks, or rerunning the same failing configuration. Source: https://github.com/morluto/rea/blob/rea-agents-6.5.0/native/windows/src/filesystem.cc No PC01 action, fresh native reproduction, or proposed security bypass is claimed.

bsakaguchi referenced this issue

2026-10-31 00:42:08 +00:00

[GH-ISSUE #5909] [Bug] Selected managed user strings claim complete coverage when method ownership is unknown #3587

bsakaguchi referenced this issue

2026-11-04 04:56:21 +00:00

[GH-ISSUE #8861] [Bug] inspect-managed-members keeps a known owner when TypeDef list starts decrease across an invalid row #7777