MEASUREMENT ONLY (proposed fix RETRACTED): declaring a read-only authorization block flips non-admin writes 201 -> 403

[rubenvdlinde]

A regression introduced by #315 (the fleet-wide x-openregister.publicRead/publicWrite removal), found while measuring the same change in portaliq.

What happened

#315 replaced the bogus publicRead/publicWrite keys with real authorization blocks — but declared read only. All 29 hermiq schemas now look like:

"authorization": { "read": ["authenticated"] }

In OpenRegister a schema with no authorization block is default-open to the authenticated pseudo-group for writes (anonymous writes are separately fail-closed, openregister#1955). Declaring any block replaces that default — so a block with no create rule denies every non-admin write.

Isolated on a live rig

Same user, same schema, same request; the only variable is the block:

schema state	non-admin POST
authorization: {"read": [...]}	403 does not have permission to create objects in schema …
no authorization block	201

Why this is worth fixing rather than keeping

The tightening may well be desirable — but it was not what #315 said it was doing. Its stated purpose was to express public read through the public group instead of a key with zero consumers. Removing non-admin write access across 29 schemas was an unreviewed side effect, and it is the kind that surfaces as "the app stopped working for normal users" rather than as a test failure, because most suites run as admin.

Suggested fix

Restore the prior behaviour exactly, then decide tightening separately:

"authorization": {
  "read":   [ ... unchanged ... ],
  "create": ["authenticated"],
  "update": ["authenticated"],
  "delete": ["authenticated"]
}

portaliq#146 does exactly this for its 13 schemas and verifies it as a pair — non-admin POST returns 400 (validation) rather than 403, and anonymous POST is still 403.

⚠️ Verify any bulk edit with a duplicate-key-detecting parser. json.load silently keeps the last of a repeated key, which is what let a malformed hermiq_register.json pass every check in the original sweep (openregister — json.load hides duplicate keys). The app ships tests/validate-json-strict.js; run it.

Also affected by the same sweep

nextcloud-app-template (#151), petstore (#53), spectr (#18) — same shape, smaller schema counts. portaliq is already fixed.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

⚠️ Correction — the fix proposed above is WRONG. Do not apply it.

tests/Unit/Settings/AgentAuthorizationTest.php failed on my own PR (#320, now closed) and its docblock describes exactly the mistake I made:

🔴 This test exists because the fix LOOKS LIKE AN OVERSIGHT. The Agent schema grants read and lists no write action at all. A reader who does not know OpenRegister’s rule sees a half-finished block and completes it — and completing it reopens a reproduced vulnerability in which any authenticated user could rewrite any agent’s tool grants, prompt, model and delegationAllowlist by PUTing the OpenRegister objects API directly.

I was that reader.

What is still true

The measurement holds: declaring a read-only authorization block does flip a non-admin write from 201 to 403, and a schema with no block is default-open to authenticated.

What was wrong

The conclusion. Omission IS the mechanism. OpenRegister fails closed on an action a non-empty block does not list — MagicRbacHandler ("an omitted action yields owner-only rows"), PermissionHandler ("if authorization is configured but the action is not granted, access is denied") — while owners and admins are admitted before that check, so the owner keeps full control of their own rows. The read-only blocks are the guard, not an unfinished edit.

Granting create/update/delete to authenticated across 29 schemas would have handed every signed-in user write access to agents, and the same shape would have done it to sessions and accounts in portaliq.

Status

• hermiq#320, nextcloud-app-template#153, petstore#55, spectr#19 — closed.
• portaliq — the equivalent commit is reverted, and portaliq now has its own guard (RegisterAuthorizationTest), negative-controlled against this exact mistake, because it had none and that is how I got as far as opening the PRs.

What this issue is now good for

Only as a record of the measurement and of the trap. If anything is worth doing here, it is per-schema intent decided by hermiq’s maintainers — not a sweep. Retitling or closing is fine by me; I am leaving it open only so the correction is attached to the claim.

Apologies for the noise. The tripwire did its job, and it did it because someone wrote down why the code looks unfinished.