gate-7 Pattern 2 assumes OpenRegister enforces per-object authz — for most of the fleet it is default-OPEN (compounds #365)

[rubenvdlinde]

Summary

gate-7 clears a #[NoAdminRequired] method that reaches storage through
ObjectService / a *Mapper on the stated reasoning that OpenRegister's
register RBAC enforces per-object authorisation one layer down
(check_no_admin_idor.py Pattern 2, and the runner's own FAIL guidance:
"If the endpoint reaches storage through a service or mapper, check whether the
guard is enforced THERE").

For most of the fleet that layer does not exist. OpenRegister's
PermissionHandler::hasGroupPermission() returns true for any schema whose
authorization block is empty or null, and the opt-in that would close it
defaults to false.

openregister/lib/Service/Object/PermissionHandler.php:1207 —

if (empty($authorization) === true || $publicOptIn === true) {
    if ($this->isDefaultClosedEnforced() === true && ...) { return false; }
    // Default-OPEN behaviour preserved.
    return true;
}

isDefaultClosedEnforced() reads
appConfig->getValueBool('openregister', 'enforce_default_closed', default: false),
and its own docblock states the reason: "the fleet ships ~15 leaf apps whose
*_register.json files do not yet declare authorization blocks. Flipping the
default would brick them overnight."

This is already known and tracked on the product side as
ConductionNL/openregister#1955 and #2011. What is not tracked is that gate-7
encodes the opposite assumption, and therefore issues a clean verdict over
exactly the endpoints those issues describe as open.

Measured — how many fleet schemas actually declare authorization

Walked every register/schema JSON shipped by each app at origin/development:

app	schemas	with authorization
shillinq	871	0
scholiq	191	0
openconnector	87	0
nldesign	50	0
doriath	1	0
zaakafhandelapp	ships no register config at all	0
pipelinq	164	1
hermiq	69	1
docudesk	72	1
procest	299	6
larpingapp	23	2
openregister	145	15
opencatalogi	74	15
openbuild	39	15
decidesk	172	24
softwarecatalog	27	21

Positive control on the lookup (an empty lookup manufactures the most
alarming possible answer for free): the same walker finds 21/27 in
softwarecatalog and 26 literal "authorization" occurrences in
softwarecatalog/lib/Settings/softwarecatalogus_register.json. The zeros are
measurements, not a bad key.

zaakafhandelapp is the sharpest case: it ships no register config, and its own
exported production register (docs/json/zaken_2026-03-27_102152.json)
carries "authorization": null on the zaken register and on all twelve ZGW
schemas. empty(null) === true → return true.

Why this matters here and not only on #2011

Combined with #365 (gate-7 accepts a no user → 401 preamble as an
authorisation guard), the two produce a gate that is silent in both directions
at once:

• the controller has no per-object check → gate-7 accepts a 401 authentication check as an authorisation guard — 4 real IDORs read as PASS (fleet-wide false negative) #365 makes gate-7 accept the 401 preamble;
• the reviewer is told to look one layer down → Pattern 2 says OR handles it;
• OR grants the action because the schema declares no rules.

Measured consequence: gate-7 reports 0 in all 18 fleet apps. With #365's
proposed fix applied, the same runs over the same trees report 423 findings.

What I am asking for

Not a Pattern-2 removal — the pattern is correct where an authorization block
exists. Two smaller things:

1. Make the assumption checkable. Pattern 2 currently applies on the
   namespace (OCA\OpenRegister) or on the presence of an ObjectService
   call. It should be conditional on the touched schema actually declaring an
   authorization block, or — if that is too much resolution for a regex gate —
   the runner's FAIL/PASS guidance should say plainly that OR is default-OPEN
   for schemas without an authorization block, so "the guard is enforced
   THERE" stops being the default reading.
2. Cross-link gate-7 accepts a 401 authentication check as an authorisation guard — 4 real IDORs read as PASS (fleet-wide false negative) #365, this issue, [MEDIUM] Object write path is default-open (anonymous/any-user create & update) openregister#1955 and #2011 so
   the three halves are not closed independently.

⚠️ Sequencing: like #365, #347, #356 and #358, any fix here has the false-RED
shape and will redden repos simultaneously. Filing, not merging.

Note on #2011's audit command

#2011 suggests grep -L '"authorization"' apps-extra/*/registers/*.json. No
fleet app has a registers/ directory — the configs live under
lib/Settings/*_register.json and lib/Settings/register.d/*.json. As written
that command matches nothing and exits reporting nothing to do, which is the
same absence-claim shape this programme keeps paying for.

---

Confirmed by: canonical ConductionNL/.github @ 112d4c9 (post-#368);
openregister @ origin/development 9628dc5d0; per-app refs listed in
/home/rubenlinde/fleet-board/findings/gate7-fleet-reaudit.md.

[rubenvdlinde]

Confirming this from the openregister side, and adding one thing that makes the
Pattern-2 argument here stronger than written: the gap is not only about writes.

enforce_default_closed covers 3 of the 5 canonical actions.

// lib/Service/Object/PermissionHandler.php:143
private const CANONICAL_ACTIONS            = ['read', 'create', 'update', 'delete', 'list'];
// lib/Service/Object/PermissionHandler.php:187
private const DEFAULT_CLOSED_WRITE_ACTIONS = [        'create', 'update', 'delete'        ];

read and list are absent by design (:176 — "Reads remain default-open since
@PublicPage is the OR-wide read model"), and it is the only such flag in the
file. So the mitigation this issue cites as "the opt-in that would close it" cannot
close reads even when enabled, and openregister#2011's definition of done
("the flag can be flipped") overstates what flipping achieves. Filed separately as
openregister#2432.

That matters for the Pattern-2 request above: a reviewer sent one layer down to
"check whether the guard is enforced THERE" finds, for a schema with no
authorization block, that neither layer enforces it —

// lib/Db/MagicMapper/MagicRbacHandler.php:390
if (empty($authorization) === true) { $qb->andWhere($qb->expr()->orX(...$ownerAdmits, ...[$notPrivate])); return; }
// lib/Db/MagicMapper/MagicRbacHandler.php:1114
if (empty($authorization) === true) { return true; }

— and the PHP layer grants via the authenticated pseudo-group at
PermissionHandler:667, which any logged-in user matches even with no group
membership.

---

One narrowing, offered against my own argument. I do not think the fleet
statement should be "OpenRegister enforces no per-object authz", because two real
backstops exist and I would rather this issue not be refutable on them later:

1. Multitenancy filtering is on by default — MultiTenancyTrait::shouldSkipFiltering()
   returns false when openregister:multitenancy is unset (:327-329) and
   enabled defaults true (:332). Cross-organisation reads are filtered.
2. Per-object private still clamps — MagicRbacHandler:390 keeps $notPrivate
   in the predicate precisely so the empty-block case does not leak private objects.

So the accurate exposure is: within a single organisation, any authenticated user
can read and list every non-private object on any schema with no authorization
block. For the apps in your table with 0/871 and 0/191, that is still every record
they hold — but it is a bounded claim, and a bounded claim is the one that survives
someone checking it.