ZDDC
88ef2dd921
The decider comment claimed standing config-edit "only ever grants VerbA, so it can never write/delete/create WORM records." True for a single decision, but it overstated the guarantee: a config-editor who administers a WORM zone can edit that zone's .zddc (inherit:false drops the embedded worm:), after which ordinary writes are no longer clamped. That two-step demotion is intended — owning a subtree's policy includes its worm: marker, and the edit is access-logged — so WORM is tamper-EVIDENT to its policy owner, not tamper-PROOF. Rewrite the comment to say so (and note where to gate worm: relaxation behind elevation if a deployment needs tamper-proof markers), and add TestStandingConfigEdit_WormDemotionIsTwoStep pinning the boundary (direct WORM write denied unelevated), the lever (config-edit allowed), and the consequence (post-demotion write allowed). Surfaced by the deferred-findings triage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| apps | ||
| archive | ||
| auth | ||
| cache | ||
| config | ||
| convert | ||
| fs | ||
| handler | ||
| jsonschema | ||
| listing | ||
| policy | ||
| tlsutil | ||
| zddc | ||
| zipfs | ||