Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

A PartitionAccessPolicy under a satellite segment, or with an id other than _Policy, is stored but never applied by the permission fold

Aperta
  • Qualcosa non va?
#7,018 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
authorization

Direzione di ricerca

Read PermissionEvaluator.ObserveScopePolicies and StorageAdapterMeshQueryProvider.IsExcludedFromResults, then inspect fix PR #7017 and RuntimeInheritanceBreakingPolicyTest in Graph.Test. The issue describes a deployed production verification and a read-only sweep for existing misplaced policies; done means deployed refusal is observed and every sweep finding is resolved.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug sev:H

What happens

A PartitionAccessPolicy node created at runtime in either of two placements is stored, can be read back by its path, and is never applied by the permission fold:

  1. a path under a configured satellite segment (for example {partition}/_Storage/_Policy, or any path containing _Thread, _Activity, _Access, _Comment, … — see SatelliteTableMapping.Defaults);
  2. any id other than _Policy (for example {scope}/MyPolicy).

A restricting policy in either placement (for example BreaksInheritance, or a narrowed permission set) therefore has no effect: the inherited grants keep granting. Nothing is logged and the write succeeds, so the author has every reason to believe the restriction is in force. That is a silently wrong access result, hence sev:H.

What it is not: it does not widen any existing grant or bypass an existing policy. The failure is that a new restriction does not take effect.

Root cause

PermissionEvaluator.ObserveScopePolicies reads a partition's runtime policies through a content query:

path:{partition} scope:descendants id:_Policy nodeType:PartitionAccessPolicy
  • A content query resolves to one storage table. Without a satellite segment in the query path, that table is mesh_nodes. Rows placed under a satellite segment live in that segment's own table on Postgres (_Storage → storage, _Thread → threads, …), and the in-memory provider drops them on purpose to mirror Postgres (StorageAdapterMeshQueryProvider.IsExcludedFromResults). So placement 1 is never returned.
  • The fold also skips any node whose id is not _Policy. So placement 2 is never considered.

A statically declared policy of the same shape does apply, because static policies are collected straight from the static node providers and never pass through the query. This static/runtime difference is how the defect surfaced (see #7013's review thread).

Fix

#7017 adds PolicyPlacementValidator to the creation chain. On Create it refuses a PartitionAccessPolicy in either placement, and the refusal names the main-node scope where the policy belongs. Pinned by RuntimeInheritanceBreakingPolicyTest (Graph.Test), including a repro on unmodified main and a negative control with the validator unregistered.

What is NOT established

  • The fix refuses new writes only. It neither removes nor applies a policy that already exists in either placement. Whether any such row exists on a deployed portal is what the read-only sweep below checks; its result is posted as a comment.
  • The sweep runs as one caller and is row-level-security filtered: partitions that caller reads only in part, and partitions it cannot read at all, are not covered. A clean sweep is therefore a floor, not a proof of absence, and the sweep comment states its denominator.
  • Paths that reach a policy write other than a generic create (for example an import that bypasses the creation chain) were not audited beyond what the PR states: a move's copy leg and an import's create branch go through the same chain.

Closing condition

sev:H closes on post-roll production verification, not on merge:

  1. the running portal(s) refuse such a create (the validator's refusal is observed on the deployed image), and
  2. the sweep for existing misplaced policies is clean, or every finding has been resolved by the owner (moved to the main-node _Policy scope or deleted).

Fix PR: #7017

Lingua principale
C#
Stelle
12
Fork
5
Merge medio
5h 57m
PR unite (30g)
967

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Systemorph/MeshWeaver

Tutte le issue di Systemorph/MeshWeaver

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.