Scope: MR-H1, MR-H2, MR-M7 from .local/security/manual-review.md.
Changes
-------
- New lib/objectAuthz.ts: canUserReadObjectPath(userId, objectPath)
performs an entity-lookup against avatar / app icon / service image /
brand logo / pdf archive / meeting attachment and applies the matching
read rule. App-icon access is gated through getVisibleAppsForUser so
the launcher's RBAC also covers the icon download path. Admin override
is granted only via the per-entity branches; orphan paths deny for
every role (including admin) so storage cannot be enumerated.
- routes/storage.ts: GET /api/storage/objects/* now calls
canUserReadObjectPath BEFORE getObjectEntityFile and returns 404 on
deny so existence is not leaked (MR-H1 fix).
- routes/apps.ts: getVisibleAppsForUser exported for the authz lib.
- routes/executive-meetings.ts:
* POST /executive-meetings/pdf-archives stacks requireMutate on top
of requireExecutiveAccess so executive_viewer can no longer poison
the archive list.
* pdfArchiveCreateSchema is now z.object({ archiveDate }).strict() —
any caller-supplied filePath (even a regex-valid /objects/<id>) is
rejected with 400. The handler always derives filePath server-side
as `print:<archiveDate>`. Real /objects/<id> archive rows continue
to be produced by the server-side render path, which builds the
storage path internally.
- lib/objectAcl.ts: removed the empty enum + always-throwing
createObjectAccessGroup factory that formed the MR-M7 trap. Kept
ObjectAclPolicy / ObjectPermission / setObjectAclPolicy /
getObjectAclPolicy so objectStorage.ts compiles. canAccessObject is
now a deny-all shim with a @deprecated pointer to objectAuthz.ts.
Tests added (artifacts/api-server/tests/storage-object-authz.test.mjs)
---------------------------------------------------------------------
A. Unauthenticated GET /api/storage/objects/* -> 401
B. Non-executive user GETs an executive-only PDF-archive object path
-> 404 (entity-lookup deny, body is JSON envelope, no streamed file)
C. Owner uploads via presign + PUT, sets users.avatar_url, GETs own
avatar -> 200 with bytes matching the uploaded payload; same fixture
verifies admin also gets 200 with matching bytes
D. Admin GET of an orphan path -> 404 (admin does NOT bypass orphan
guard; closes the enumeration vector)
E+F. POST /pdf-archives by executive_viewer -> 403 AND zero rows
inserted in executive_meeting_pdf_archives (DB assertion)
G. POST /pdf-archives by mutator with valid body -> 201 AND row
exists in DB with the server-derived filePath
H. Authed user GET of an orphan path -> 404 (regression)
I. POST /pdf-archives with a caller-supplied filePath -> 400
J. GET /pdf-archives by executive_viewer -> 200 (regression)
K. Brand-logo path: real upload + presign, wired to font_settings.
logo_object_path; on the SAME existing object the executive_viewer
streams 200 + bytes while the order_receiver gets 404 — proves the
divergence is from authz, not from missing-file behavior
Test results
------------
All 10 new tests pass. Full api-server suite: 319/324 pass. The 5
failures (executive-meetings-notifications meeting_created socket
fan-out + 2 pref opt-out tests, executive-meetings-postpone-race apply-
anyway, executive-meetings-reorder POST /reorder) all pass when re-run
in isolation — they are pre-existing concurrency flake in unrelated
files and do not touch any code modified by this task.
Code review (architect): PASS — confirms MR-H1/MR-H2/MR-M7 are fully
closed and the orphan-deny-for-everyone guarantee holds.
Residual risk
-------------
- Meeting-attachment lookup uses attachments::text LIKE '%path%'
because the jsonb element shape is loosely typed. Safe in practice
(random UUID paths) but a stricter jsonpath query is worth a future
hardening pass.
- Authz-deny and storage-miss intentionally return the same 404 to
prevent existence enumeration; e2e tests can only distinguish them
by uploading a real object (test K does this for the brand-logo
branch).
Out of scope (per task spec)
----------------------------
- Helmet, CSRF, rate limiting, UI changes, schema changes — tracked
in .local/security/manual-review.md and proposed as follow-up
Task #525 (auth rate limiting, MR-H3).
riyadhafraa
0c8da09ea0