Repository navigation
fix(erasure): keep operator scratch that is not owner-only instead of planning it (#1468) - #2495
Merged
Merged
Conversation
… planning it (#1468) Owner decision 2026-10-23 (option 2). ccc-erasure-apply.py refuses a whole run when any target is not owned by the effective uid or has a group/other permission bit; on the first node measured, 24 of 45 scratch files were 0644/0755, so every prune-expired run there would have been refused, and a chmod would restart the 90-day clock (ctime). The planner now applies the same owner-only test (`_owner_only`, mirroring check_ancestors' target test) to the `state.operator_scratch` fallback and plans such files as `retain (not owner-only)`. Rule order: live claims -> key file -> symlink -> owner-only -> scheduler guard -> age. Named retention classes are unchanged. Tests: ccc_erasure_retention_test.py 45 OK (2 new; the main one fails with the rule disabled), planner 57/0, apply OK, handoff 16/0, security audit 18/0, ruff clean, canon-node-name-scan baseline. Refs #1468 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…-independent CI runners use umask 022, so `fresh-handover.md` was created 0644 and, under the new owner-only rule, planned `retain (not owner-only)` instead of `retain-until`, failing "scratch: unknown state file planned as operator scratch (retain-until)" on validate-harness-shard (3). Locally (umask 077) it passed. chmod 600 the fixture, and add an explicit 0644 case asserting `retain (not owner-only)`. ccc-erasure-planner.test.sh PASS=58 FAIL=0 under umask 022 and 077. Refs #1468 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
seoseo-ai
approved these changes
Oct 23, 2026
seoseo-ai
left a comment
seoseo-ai
left a comment
Collaborator
There was a problem hiding this comment.
Approved after exact-head validation and fresh operator authorization using the relay-held seoseo-ai credential.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Owner decision 2026-10-23 on #1468 (option 2): operator scratch that is not owner-only is kept, not planned for deletion.
ccc-erasure-apply.pyrefuses a whole run when any target is not owned by the effective uid or has a group/other bit (check_ancestors:owner-not-euid/group-other-bits-on-target). On the first node measured, 24 of 45 scratch files were0644/0755, so every prune-expired run would be refused — andchmod 600would refresh ctime and restart the 90-day clock.scripts/ccc-erasure-planner.py:_owner_only()(same target test as apply) applied to thefallback_scopeclass only →retain (not owner-only). Rule order: live claims → key file → symlink → owner-only → scheduler guard → age.docs/erasure-closeout.mdrule order) + changelog fragment.Verification
ccc_erasure_retention_test.py45 OK (2 new: non-owner-only scratch at 0644/0755/0640 → retain for prune-expired and decommission while owner-only scratch → delete and passesapply.check_ancestors; rule does not touch a named class). The main new test fails with the rule disabled.retain (not owner-only)+ 21retain-until, 0 delete.Still open
On that node 3 group-b crontab backups are also not owner-only, so a prune-expired run would still be refused there. Not changed here (retaining group b would defeat its purpose) — separate owner decision on #1468.
Refs #1468
🤖 Generated with Claude Code