Documentation
¶
Overview ¶
Package pools answers one question: which resource memory pools may this session touch, and in which direction?
It reads SpiceDB and returns memory scopes (package memory, for Scope and ResourceScope). It deliberately does NOT import the memory facade — the facade's authorizer consults this package, and nothing in package memory imports pools back, so there is no cycle between the two. A cycle would make either untestable in isolation.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Pools ¶
type Pools struct {
// Read pools: every resource the session holds ANY slot on. Reading a pool
// is disclosure its audience already permits.
Read []memory.Scope
// Write pools: only those held under a write_memory slot. Writing is an
// egress into someone else's pool, so it needs its own grant.
Write []memory.Scope
}
Pools are one session's resource memory pools, split by direction.
func ForSession ¶
ForSession returns the pools the session may touch.
A slot grant is <type>:<id>#slot_grant_<perm>@agentsession:<ns>/<name>, and the relation is PER-PERMISSION. So the read/write asymmetry the spec calls for is readable directly off the tuples: any slot_grant_* makes a read pool, slot_grant_write_memory makes a write pool. Nothing tracks it separately, so nothing can drift out of agreement with what was actually granted.
Results are sorted. They become minted approvals and pt-tags, both of which must be a pure function of the grant set rather than of SpiceDB's row order.
Source Files