rabadon

overview / blind spots / a walk that never spells the law's name

a walk that never spells the law's name

A walk of the project's own contents: `.rabadon` is swept up as one entry among many and is never named, so there is no operand for the rule to judge.

the shapes

15 of the 21 shapes rabadon's gate allows although they destroy .rabadon/guard.json, measured and declared by the binary:

find . -delete find . -not -name . -delete find . -not -path . -delete find . -not -type l -delete find . -not -newer . -delete find . -mindepth 1 -delete find . -depth -delete find . -name '*' -delete find . -exec rm -rf {} + find . -type d -exec rm -rf {} + find . -mindepth 1 -maxdepth 1 -exec rm -rf {} + ls -a | xargs rm -rf ls -A | xargs rm -rf ls -a | xargs -I{} rm -rf {} printf '%s\ ' .* * | xargs rm -rf

From the kLawBlind table in native/gate.cpp; rabadon-gate --law-blind prints it.

why the gate cannot see them

Shapes that destroy the law and are allowed. baseline-law-unmade judges a command's operands. Each shape below removes <project>/.rabadon/guard.json without an operand naming it, so it is ALLOWED. Deliberately not closed: refusing a recursive walk or rm -rf ./old-project would fence users inside their own project (docs/guard.md). They are disclosed on the blind spots: screen and by --law-blind; native/law_blind_test.sh holds this table equal to the gate's behaviour over native/lawblind_corpus.txt.

what to do

What to do: commit .rabadon/ to git. That copy survives all twenty-one, and git checkout .rabadon puts the law back. Under rabadon exec a protectedPaths entry is additionally fenced by the kernel.

rules

baseline-law-unmade