[security-sensitive] sys_file mime_type/size are writable via the data API — may neutralize field accept/maxSize re-check (verify non-admin)

[baozhoutao]

Surfaced by QA run #10663 (attachments-storage.field-accept-maxsize-server-enforced) at 79ebb37. Existence + mechanism only; full reproduction withheld pending maintainer review per the auth/authz disclosure carve-out — available in the QA session on request. This one is a HYPOTHESIS for the non-admin case — only the admin path was proven.

What

The server-side accept/maxSize re-check on record write reads sys_file.mime_type and sys_file.size, and those columns are writable through the ordinary data API (PATCH /api/v1/data/sys_file/<id>). A caller who can PATCH a sys_file row can null those fields; the accept/maxSize check then has nothing to test against and passes (the documented "missing metadata is not a violation" boundary), reachable on demand.

What is proven vs. open

• Proven (as the seeded platform admin): nulling mime_type/size on a sys_file row succeeds and lets a subsequent write bypass the field's accept/maxSize constraint. As admin this is expected privilege, not a hole.
• Open / needs a run: whether a non-admin file owner (or any caller who can reference the row) can PATCH those columns. If yes, the field-level accept/maxSize control is bypassable by an unprivileged caller — an authz-adjacent defect. If RLS/FLS blocks the non-admin PATCH, this is a non-issue.

Mechanism (fix-oriented)

sys_file.mime_type/size are not treated as system-managed/immutable after commit, so the metadata the constraint check trusts is caller-mutable. Fix direction (if the non-admin case confirms): make those columns immutable post-commit, or re-derive them server-side rather than trusting the stored value at check time. Note the broader boundary: enforcement is declaration-based, not content-based (no magic-byte sniffing anywhere on the upload path) — tracked separately.

Next step

A follow-up run as a non-admin file-owner persona resolves the open half. I can run it if you want the answer before deciding.

QA-source: #10663 · attachments-storage.field-accept-maxsize-server-enforced · knownGap (content-boundary / metadata-mutability)

[os-zhuang]

Triage: lands in packages/services/service-storage (src/objects/system-file.object.ts owns sys_file; the trusting consumer is the accept/maxSize re-check reading the row, cf. packages/objectql/src/engine.ts:7969) ⇒ pm:queue · domain:services · type Task (premise-first measurement; flips to Bug only if the non-admin half lands).

Dispatch notes for the executing seat:

• Premise-first, in this order: ① measure whether a NON-admin file owner (or any caller who can reference the row) can PATCH /api/v1/data/sys_file/ on mime_type/size. If FLS/RLS already blocks it ⇒ close with the measurement as evidence (premise_still_valid: false + no PR is a good run — the admin-path half is expected privilege, per the card itself). ② Only if the non-admin PATCH lands: fix by making those columns system-managed/immutable post-commit (or server-side re-derive at check time) — do not widen anything.
• Clause-② yes if phase ② runs: making previously-writable columns immutable narrows accepted writes on a published data surface. Contract-review tier applies to that half.
• The broader content-vs-declaration boundary (no magic-byte sniffing) is explicitly out of scope here — the card says it is tracked separately; do not fold it in.
• Reproduction withheld per the disclosure carve-out (QA session QA run · scan-functionality 14-item scope · 7 pass / 7 fail (14/14 adjudicated) · 79ebb37 · 2026-08-21 #10663).

Size/model suggestion: M, opus (measurement + possible tightening).

---

Generated by Claude Code

[os-warren]

Claim: dispatched as measurement-only. No code change is authorised by this dispatch.

• session: user-29 [974948]
• branch: claude/issue-10702-sysfile-metadata-mutability
• worktree: ../objectstack-10702
• Clause-②: not applicable at this tier — this dispatch changes no code. If the measurement comes back positive, the fix is a separate card and it will be Clause-②.
• serial constraint: service-storage / sys_file metadata surface. Freed by fix(service-storage): tombstone attachments on a predicate delete #10951 (merged). No other services card holds it.

Why measurement-only, and not a fix

The card's own split is the reason. What is proven is the seeded platform admin nulling mime_type/size — and the card says so itself: "As admin this is expected privilege, not a hole." What is open is the only half that decides whether a defect exists at all:

whether a non-admin file owner (or any caller who can reference the row) can PATCH those columns … If RLS/FLS blocks the non-admin PATCH, this is a non-issue.

Dispatching a repair now would be building a fix for a defect nobody has shown exists. The answer to that one question is the entire deliverable.

The one question

Under RLS/FLS as shipped, can a non-admin caller — specifically a file owner, and separately any authenticated caller who can reference the row — succeed at PATCH /api/v1/data/sys_file/<id> writing mime_type and/or size?

Answer it both directions, and make the negative provable:

• A refusal must be shown to be a refusal, with its ADR-0112 envelope — assert code AND status (ADR-0112), not status alone. A 200 carrying an empty result is not a refusal, and this lane has been bitten by exactly that shape (fix(plugin-auth): a 2FA verification echoes the session it installed, not the one it deleted #10954: get-session answers 200 for anonymous).
• A success must be shown to actually persist — read the row back, do not trust the write's response.
• Positive control on the same persona and corpus: prove the non-admin CAN write something on that row (or that the row is reachable at all), so a refusal is a refusal and not a broken fixture, a missing row, or a mis-seeded persona. Without it, a clean "denied" is indistinguishable from "the test never reached the endpoint".
• ⛔ approvals: a department approver never resolves when the business unit has organization_id = null (every seeded BU) #3807 applies: null is not "not mine". Do not read a null/absent result as a denial.

⛔ Disclosure discipline — binding

This card is under the auth/authz carve-out. The full reproduction stays in QA session #10663 and must not be restated.

• No reproduction recipe in the PR body, the card, any commit message, or any comment — not the request shapes, not the persona-seeding steps, not the field values that trigger it.
• Report the verdict and the mechanism, not the path to it. "A non-admin file owner can/cannot persist mime_type on their own row; the control that decides it is X" is the shape to aim for.
• If you need the withheld detail, ask on QA run · scan-functionality 14-item scope · 7 pass / 7 fail (14/14 adjudicated) · 79ebb37 · 2026-08-21 #10663 rather than reconstructing and publishing it.

Outcomes and what each means

measurement	what you file
non-admin PATCH refused with a real envelope, positive control green	report it; recommend this card be closed as a non-issue, with the control named. Do not close it yourself.
non-admin PATCH succeeds	this is an authz-adjacent defect. Report needs_decision with the measurement. Do not fix it here — the fix (immutable-post-commit vs. server-side re-derivation at check time, per the card's own two directions) is a permission-boundary change and a separate Clause-② card.
you cannot reach a verdict	say so with the measurement that blocked you. A gate or harness that refuses is NOT MEASURED, never a pass.

Standing instrument traps (all measured in this repo)

• A gate's refusal (PREREQUISITE NOT MET … Nothing was checked) is NOT MEASURED, not green.
• An unwired script name exits 254 Command not found and reads GREEN through a pipe.
• Capture exit codes before any pipe (cmd > file 2>&1; EXIT=$?), never after a tail.
• Do not report a grep hit count as a fact count — this lane has been wrong that way four times today.
• Worktree-first, per repo. Never git stash — the stack is shared across every worktree of this repo and a pop reports success while taking another agent's work.

Refs

QA #10663 (parent; holds the withheld reproduction) · #10951 (freed this surface) · #3807 · ADR-0112

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 10702,
 "status": "needs_decision",
 "branch": "claude/issue-10702-sysfile-metadata-mutability",
 "pr": null,
 "premise_still_valid": true,
 "summary": "Measurement-only run; no product code changed, no PR. VERDICT on the open half: under the platform baseline AS SHIPPED, a non-admin cannot write sys_file.mime_type/size through the generic data API. Both personas — the file owner (owner_id server-stamped to them) and a second authenticated non-owner — were refused with HTTP 403 / code PERMISSION_DENIED on the update, and a system-context read-back confirmed the stored values were unchanged. The refusal is object-level RBAC, not a protection of those columns: the server logged \"Access denied: operation 'update' on object 'sys_file' is not permitted for positions [everyone]\", i.e. the control is that the explicit-allow platform baseline (member_default, #5491) NAMES no sys_file grant. Nothing else guards the columns: sys_file declares no managedBy bucket, so it defaults to the writable 'platform' bucket and the ADR-0103 engine-owned write guard does not cover it; mime_type/size are not readonly (the same update DID exercise readonly stripping on organization_id/created_by/updated_by/created_at, so that mechanism is live on this row and simply does not cover these two); no FLS or hook intercepts them. Second posture measured for mechanism: with an app-authored wildcard object grant union-merged on top of the same platform baseline, BOTH non-admin personas got 200 and the null-metadata write PERSISTED (verified by system read-back) — including the non-owner, so neither ownership nor the platform ownership-floor RLS caught it. So the decision the card needs is whether an app-revocable grant absence is the right control for a row a security re-check trusts. I did NOT survey every shipped app: the showcase example's permission sets contain no wildcard and no sys_file grant (read, not counted), so nothing shipped opens it today.",
 "tests": "Throwaway harness only — two @objectstack/dogfood probe files (not committed, deleted after the run), driven through the real in-process HTTP stack (bootStack + better-auth sign-up + /api/v1/data routes) with StorageServicePlugin and the real presigned upload path. Dependency closure built first: `pnpm --workspace-concurrency=2 --filter '@objectstack/dogfood^...' build` -> `os-verify-lock: VERDICT command-exit 0 - held the lock 433s`. Runs: `pnpm --filter @objectstack/dogfood exec vitest run --maxWorkers=2 <probe>` -> `os-verify-lock: VERDICT command-exit 0` and `Test Files 1 passed (1) / Tests 3 passed (3)` for each posture. Measurements were written to a JSON artifact rather than asserted, so a pass is not the verdict — the recorded envelopes are. As-shipped posture: owner GET 403/PERMISSION_DENIED, owner update 403/PERMISSION_DENIED persisted:false (both a value write and a null write), non-owner identical. Positive controls, same personas and same route family: each member created (201) and updated (200) an app-object record and the new value was read back from the store. Contrast control on the SAME row and the SAME two columns: the seeded platform admin got 200 and the change persisted, which proves the id, the route, the column names and the fixture were all real — the members' 403 is a refusal, not a fixture that never reached the endpoint. Permissive-app posture: owner and non-owner both 200 with persisted:true on read-back. No ablation was applicable (no guard added or removed). Gate union: NOT APPLICABLE — the working tree is clean, no product source was touched and nothing was committed, so `dispatch-gates` has nothing to derive.",
 "open_questions": [
 {
 "question": "The non-admin write is refused as shipped, but only because no shipped permission set names sys_file — the columns themselves are ordinary writable data on a 'platform'-bucket object, and any app that grants edit on it (wildcard or explicit) hands a non-admin the accept/maxSize bypass, owner or not. Close as a non-issue, or harden the columns?",
 "options": [
 "A - Close #10702 as a non-issue on the measured refusal, naming the control (member_default is explicit-allow and names no sys_file grant; the admin path is expected privilege per the card).",
 "B - Keep it open and re-scope it to a Clause-2 card: mark sys_file as engine-owned (ADR-0103 managedBy) or mark mime_type/size readonly/system-managed post-commit, so the re-check's inputs are not caller-writable regardless of what an app grants.",
 "C - Close #10702 and file a narrower follow-up instead: make the accept/maxSize re-check re-derive the metadata server-side at check time rather than trusting the stored row, leaving the data surface untouched.",
 "D - Close as non-issue but add a pin that locks in the measured refusal, so a future baseline change that grants sys_file writes to members turns a gate red."
 ],
 "recommendation": "B, with D as a cheap rider. Real business need: nobody is writing sys_file.mime_type through the data API — the columns are stamped by the upload path, and the showcase app grants nothing on the object, so making them non-caller-writable removes an affordance with no measured consumer rather than adding a feature. Long-term soundness for this project: the accept/maxSize re-check is a declared security property, and today its inputs sit on a writable 'platform'-bucket row whose only defence is an absence — that is exactly the workaround-shaped posture ADR-0103 introduced the engine-owned bucket to end, and A leaves a security control's trust anchor governed by app-authored RBAC. Making AI-written metadata hard to get wrong: an AI author who ships one permissive profile silently re-opens a file-type/size control it has never heard of, and nothing refuses at publish time — 'declared = enforced' should mean the platform's own trusted columns cannot be granted away by an app's profile. Startup scope discipline argues against C (a new derivation path on the upload/check hot path is more surface than the defect earns) and against widening anything; B is a narrowing of an unused write affordance, which is the cheap direction. Where the axes conflict: startup discipline does favour A as zero work, and A is defensible today because nothing shipped opens it — my measurement cannot settle whether the maintainer considers an app-revocable grant an acceptable control for a platform security input, so that call is theirs.",
 "recommendation_axes": {
 "real_business_need": "No measured consumer writes these columns through the data API; the upload path stamps them (owner_id was server-stamped in the run). Removing the write affordance costs nothing observed.",
 "long_term_soundness": "The re-check's trust anchor should not be app-grantable. Engine-owned/readonly is the contract-first fix; leaving it to RBAC is defence-by-absence.",
 "ai_authoring_safety": "One permissive app profile silently disarms a field-level accept/maxSize control. Structural immutability makes that unauthorable.",
 "startup_scope": "B narrows an unused surface (cheap); C adds a derivation path on a hot path (more than this earns); A is free but leaves the control app-revocable."
 }
 },
 {
 "question": "Should the throwaway harness be kept as a pin?",
 "options": [
 "A - Keep nothing; the measurement is recorded here.",
 "B - Keep a pin asserting the as-shipped refusal envelope (403 + PERMISSION_DENIED) for both non-admin personas, with the admin contrast control."
 ],
 "recommendation": "B, but ONLY as part of whichever card the maintainer picks above, and authored so it reads as a refusal pin rather than a recipe — the harness as written is the reproduction and is deliberately not committed here. I did not open a PR for it because this dispatch is measurement-only and the disclosure carve-out makes an uncommitted probe the safer default."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code