@argszero/cordis-plugin-sandbox-grant-advisor 0.9.0 → 0.9.1

package/cordis.patch.yml

@@ -1,8 +1,9 @@
 # The @argszero/cordis-plugin-sandbox-grant-advisor bundle patch: mount and go.
 #
-# Three reports (#7538, #7622, #7646) describe one Windows failure with no way
-# forward: the host-side write grant for a sandboxed workspace cannot be
-# applied, so every sandboxed command fails before it runs with
+# Twelve reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804,
+# #7816, #8232, #8272, #8275) describe one Windows failure with no way forward:
+# the host-side write grant for a sandboxed workspace cannot be applied, so
+# every sandboxed command fails before it runs with
 #
 #   SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)
 #
@@ -24,8 +25,25 @@
 #     (the manifest half of the merged DACL+SACL write is what needs it);
 #   - the directory's own ACL is the discriminator (`icacls <dir>`, looking for
 #     an ACE that names your SID with (F));
-#   - the remedy is one unelevated line:
-#       icacls "<dir>" /grant "$env:USERNAME:(OI)(CI)F"
+#   - the remedy is one unelevated line, forked on ownership because one command
+#     cannot serve both rights situations — the advisory hands over the check
+#     (`(Get-Acl "<dir>").Owner`) rather than guessing:
+#       icacls "<dir>" /grant "$env:USERNAME:(OI)(CI)(WO)"
+#     with Full control (`F`) offered second as the same line with more than it
+#     needs, and an elevated grant for a directory the caller does not own (where
+#     `icacls /grant` is itself refused for want of WRITE_DAC);
+#   - two version boundaries the error cannot carry: the mandatory label — and
+#     with it the SACL — arrives in `0.1.7-alpha.1` (up to `0.1.6-alpha.x` the
+#     apply touched the DACL only), and the backend's own
+#     `diagnose-windows-sandbox-acl` repair arrives with the `0.2.0` line. Neither
+#     makes downgrading a fix, and repairing the `0.1.7` file list is not a thing
+#     that can be done — there is nothing in that release to list.
+#
+# The advisory also says why a "weaker grant" is not a smaller version of the
+# same one, because that is the next idea the diagnosis invites: the label rides
+# the SAME SetNamedSecurityInfoW as the DACL (no DACL-only apply path exists), and
+# the confined token is itself lowered to Low, so the directory's Low label is
+# what lets that child write there at all.
 #
 # Optional config:
 #

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@argszero/cordis-plugin-sandbox-grant-advisor",
   "description": "Turns three sandbox environment failures that name neither their cause nor a remedy into a diagnosis with a path forward. Family 1, the Windows workspace ACL: twelve reports (#7538, #7622, #7646, #7720, #7750, #7735, #7771, #7804, #7816, #8232, #8272, #8275) of one signature \u2014 every sandboxed command fails before it runs with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)`, because the merged DACL + mandatory-label write needs WRITE_OWNER on the directory (an object right the caller can self-grant), not SeSecurityPrivilege and not elevation; the host grant is materialized lazily and caches nothing on the failure path, so the same failure repeats per command. Family 2, the persistent shell (#7638): with the `minimal` preset under a confining sandbox mode every shell call dies instantly with `PTY shell exited during startup` because the terminal backend cannot create the pseudo-console inside the sandbox, retrying never helps, and `minimal` mounts no fallback shell tool. Family 3, a confined Windows child that died during native initialization (#7876, #7877): every command spawned through the sandbox runner can report exit 0xC0000142 STATUS_DLL_INIT_FAILED with the process never reaching its entry point \u2014 the packaged desktop starts that runner as [process.execPath, entry], and that host has been measured twice with one indistinguishable appearance from inside a session \u2014 either nothing on the runner path ran because the Electron binary launches as an application unless the child's environment carries ELECTRON_RUN_AS_NODE=1 (#7876), or the desktop launcher does set that variable and the child still dies because the restricted token is derived from the Electron process image (#8193), and an MSYS2 / Git-Bash program cannot create its signal pipe under the restricted token while cmd.exe and pwsh run fine in the same workspace under the same mode (#7877) \u2014 and because upstream's runner-failure rules admit only exit 127 with the `windows-acl-run: ` signature, the code is never an error: it arrives as the canonical value of a result the pipeline calls a success. The plugin observes the public `tools/post-execute` waterfall, classifies all three signatures narrowly (only the two `...NamedSecurityInfoW` operations; the PTY message matched on a whole line, never as a substring; the loader status read as a 32-bit integer out of the shell tool's own canonical success value, never from rendered text; both mode-gated families advised only under a mode the policy resolver reports as confining), and attaches ONE durable user-role advisory per agent per family through `additionalContexts`. The ACL advisory names the missing right, both environments the identical text can describe (an inherited Modify-only entry, a data volume where no ACE names the caller at all, and a directory owned by another account), the version boundary that arrived with the mandatory label (0.1.7-alpha.1, flag 20, versus the DACL-only flag 4 up to 0.1.6-alpha.x) together with why downgrading is not the remedy, the second boundary the later reports needed (the backend's own `diagnose-windows-sandbox-acl` skill is not part of the 0.1.7 line at all — it arrives with 0.2.0, measured on both published tarballs: 0.1.7-rc.2 names it zero times in either README, ships no assets, and carries no registration symbol anywhere in its tree, while 0.2.0-rc.2 ships assets/diagnose-windows-sandbox-acl/ and names it three times per README — so a reader who found the promise in a README was reading a 0.2.0-era document, and sending them to repair a files glob would be the wrong repair), and why a \"weaker grant\" is a mechanism the backend cannot express rather than a policy it declines (the label rides the SAME SetNamedSecurityInfoW as the grant — there is no DACL-only apply path to fall back to — and the confined token is itself lowered to Low, so the object's Low label is what lets the confined child write there at all; declining the label usefully means declining the token level with it), the discriminator, the remedy forked on an ownership check the user runs (`(Get-Acl \"<dir>\").Owner`), because one command cannot serve both rights situations: where the caller owns the directory, the unelevated `icacls ... :(OI)(CI)(WO)` is the whole of what is missing \u2014 the owner's implicit WRITE_DAC already covers the DACL half \u2014 and where the caller does not own it that same command is refused for want of WRITE_DAC, so the grant has to come from an elevated account, or by taking ownership first, or by moving the workspace under %USERPROFILE% \u2014 and the two remedies that look right and are not (`takeown`, `icacls /reset`), each with the reason it fails — and it states the two things about the failure's shape that the reports had to measure for themselves (#8232): that it belongs to the workspace rather than to the command (a command that only reads fails identically, so there is no harmless retry), and that the grant is scoped to the directory it names and its children, so a sibling workspace root on the same volume needs the line once more; the PTY advisory names the failing combination, states the resolved mode, tells the model to stop rather than retry, and hands the user-side preset choice over \u2014 it never names a shell tool the failing composition does not mount; the native-init advisory states the resolved mode, says the process died before its entry point, enumerates the two producers measured under a confining mode \u2014 naming both measured shapes of the desktop host rather than asserting the one that was measured first \u2014 with the check that separates them (what program the reader ran; whether this host is the packaged desktop binary, which the plugin measures and reports rather than assumes), carries the one conversion a model can make itself (rewrite the work as PowerShell or `cmd` when an MSYS2 program is what could not start), and \u2014 for the Electron host \u2014 names the fix #8193 measured rather than a wider mode: host the runner on a real node.exe (the desktop ships one under `resources/runtime/primary-runtime/dependencies/node/bin/node.exe`), where the same confined `pwsh`/`cmd` spawns succeed, while `danger-full-access` is described as a way to confirm the diagnosis and not a fix, together with the warning that unsetting `ELECTRON_RUN_AS_NODE` instead would leave the desktop's Electron-hosted runner unable to execute `runner.js` at all (the interaction #8193 records with #8174), and says plainly which producers it does not know \u2014 it never claims the sandbox caused the failure and never offers a widened mode as a fix. An optional, off-by-default `enforceAfter` refuses an identical ACL call this plugin has watched fail, bounded by `maxDenials`; the blocking half is ACL-only by design. It never edits an ACL, never elevates, never sets another process's environment, and never changes a preset or a mode, and it complements repeat-guard-escalation, which keys on call identity rather than on the environment signature.",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",