admin/my-pi
1
0
Fork 0
mirror of https://bitbucket.org/siakitem/my-pi.git synced 2026-08-28 08:35:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat: vendor permission system source

Browse Source
This commit is contained in:
云服务部-叶林立
2026-08-19 14:35:19 +08:00
parent 198584daf8
commit 410c50a3e5
809 changed files with 157793 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pi-permission-system/docs/migration/0635-forwarded-ask-delegation-envelope.md
+42
View File
@@ -0,0 +1,42 @@
# Migration guide: forwarded asks and the bounded-delegation checkpoint
Starting with the release that closes #635, a permission request forwarded up from a subagent carries the **child-fixed access facts** through to the authorizer chain.
As a side effect, the bounded-delegation checkpoint now applies to forwarded asks the same way it already applied to local ones.
This is a **breaking change** for one narrow configuration.
## Who is affected
You are affected only if **all** of the following hold:
- You name an authorizer chain link in `authorizerChain`, and
- that link is **allow-capable** (it can return `allow`, not only `deny` / `defer`), and
- a subagent forwards an `ask` to your session that was raised by the `path` or `external_directory` gate.
If you run no chain link, or run only a deny-first link — including the first-party [`@gotgenes/pi-permission-model-judge`](https://github.com/gotgenes/pi-packages/tree/main/packages/pi-permission-model-judge), which only ever denies or defers — **nothing changes for you**.
## What changed
The checkpoint downgrades a link's `allow` to `defer` on the excluded surfaces (`path`, `external_directory`), so the request falls through to an interactive prompt instead.
It selects the surface from the **gate** surface — the surface the matching rule lives on — falling back to the displayed surface when no gate surface is available.
A forwarded request previously arrived with no gate surface, so the checkpoint fell back to the child's *display* surface, which is the tool name (`write`, `edit`, `read`).
A tool name is not an excluded surface, so a link's `allow` on a forwarded `path`-gated request was honored.
The identical request made directly in the same session was capped, because a local request always carries its gate surface.
Forwarding was therefore a way around your own delegation boundary: a link could approve `~/.ssh/config` for a subagent that it could not approve for the main session.
Now the gate surface crosses the forwarding hop, and both paths behave identically.
Unchanged: a forwarded `bash` ask, and a forwarded tool ask gated by a per-tool rule (`write: ask`), are both already on non-excluded surfaces and are not capped.
`deny` and `defer` verdicts were never capped and still are not.
## What you need to do
Nothing, unless you run an allow-capable link.
If you do, expect an interactive prompt where that link previously auto-approved a forwarded subagent request for a path.
To keep such a request from prompting, grant it in policy rather than through the link — the `path` and `external_directory` rules in your config are consulted before the chain runs, so an `allow` there resolves the request without reaching an authorizer at all.
## Related
Issue #620 will replace the whole-`path` exclusion with a narrower secret-shaped one, letting a link allow a non-secret path again while keeping secret-shaped paths capped.
That refinement applies to local and forwarded asks alike, so the two paths stay aligned.