Answer prose round 1: 0 🔴, 3 🟡 (0 misread); the pageError comment is true, nested-group removal is unambiguous, the trade-off lives only at the guard
CI / full-gate (push) Successful in 3m20s
Mirror / github-mirror (push) Successful in 4s

This commit was merged in pull request #195.
This commit is contained in:
2026-10-31 11:02:47 +01:00
parent 8906340cf8
commit b478cc7735
2 changed files with 8 additions and 8 deletions
+3 -4
View File
@@ -214,10 +214,9 @@ Revisit only if the stated reason stops holding.
grant-specific guards go with it: you cannot revoke your own **direct** grants (self-lockout would
need a `curl` against Keto to undo), and a permission held *through a group* renders
ticked-but-disabled, because unticked stated the opposite of the truth. The group paths are
guarded too: unticking a permission on a group you are in, removing yourself or a group you are in,
or deleting the group is refused when you would lose a permission you don't hold directly. One also
held through another group counts as lost — telling them apart needs a reverse Keto query, and a
false refusal costs only asking another administrator.
guarded too: unticking a permission on a group you are in, removing yourself (or a nested group you
are in) from its members, or deleting the group is refused when you would lose a permission you
don't hold directly.
- **`users:write` and `groups:write` are equivalent to full administrative access**: `groups:write`
adds you to any group, including one holding every permission; `users:write` mints a recovery code
for any account. The containment the split buys is real on the **read** half only (`users:read` is
+5 -4
View File
@@ -8,10 +8,11 @@ at boot. Entries start at 0.3.0.
### The admin example stops an administrator locking themselves out through a group
On the Groups screen, unticking a permission on a group you are in, removing yourself or a group
you are in, or deleting the group is refused when it would take away a permission you don't hold
directly. The page says so, and another administrator can make the change. A permission you also
hold through another group counts as lost, so such a change is refused as well.
On the Groups screen, unticking a permission on a group you are in, removing yourself (or a nested
group you are in) from its members, or deleting the group is refused when it would take away a
permission you don't hold directly. The page names the permissions, and another administrator can
make the change. The check errs towards refusing: it also refuses when you would keep the permission
through another group, or keep your membership another way.
### The admin example titles a read-only user page "View user"