[Decision] should a file field's sys_file metadata (name, size, type) follow the holding record's read, as the download door and attachment rows already do? (access half of #22593) #22624

Ruled: 6094990917 · letter B · 2026-10-10T07:12Z

Filing gate: ② a decision only the maintainer can make. This is the access half of #22593, which that card sends to the maintainer: whether a file field's sys_file metadata (name, size, type) should follow the holding record's read, the way the download door and attachment rows already do. Answering yes loosens sys_file's read boundary. Filed by domain:engine seat 2 (seat post #20966) · session_01Bw3y2DWhT9RPnrmDsNqEVG, from the read-only measurement in #22593's os-dev-report (access_half, 6094498292). ⛔ Not graded or routed here; ⛔ not a claim. Ruled B (6094990917); carrier: the domain:engine seat on #22593.

Who acts on it: the maintainer answers one letter; triage grades it; the domain:engine seat carries the answer. #22593's loud half (PR #22620) does not wait for it. It marks a refused hydration { id, metadataRefused: true } instead of a bare id that reads as "no file".

维护者速读

• 现象(hotclm 实测,17.7.0;main 上复现): 一个能读合同版本、但没有 sys_file 读权限的申请人,看自己刚上传的文件字段,显示「没有文件」。objectql: a file field reads "no file" for a record reader without sys_file read: the hydration lookup runs as the caller, and a refusal reads as absent data (split from #22590 item 1) #22593 的显式那一半(PR fix(objectql): a refused sys_file read marks the file field refused instead of reading as no file #22620)把它改成「有文件,但详情无权查看」,不再冒充空值。
• 剩下的问题: 这个人能不能看到文件的名字、大小、类型?
• 今天的规则自相矛盾:
  • 下载入口从持有记录推导权限:能读这条合同记录,就能下载字段里的文件字节。
  • 字段水合只看 sys_file 的对象读权限。默认成员权限集没有这项,所以同一个人能下载文件内容,却看不到文件名。
  • 附件行也已经跟随父记录。
• 推荐 B: 文件元数据的读权限,按下载入口已经在用的同一条推导规则来:字段所属的文件,能读持有记录就能读元数据。直接查询 sys_file 的规则不变。回一个字母:A / B / C。

一句话问题

能读一条记录的人,能不能看到这条记录文件字段里文件的名称、大小和类型?

Background (read on faf689872c, from #22593's access_half; read-only, nothing changed)

• sys_file read today.
  • SystemFile (service-storage/src/objects/system-file.object.ts:21) declares no access block and no sharingModel; it is tenant-scoped.
  • The read is the object CRUD gate PermissionEvaluator.checkObjectPermission('find', 'sys_file', …) (plugin-security/src/permission-evaluator.ts:205). It passes only when a set grants allowRead on sys_file or '*'.
  • Shipped sets: '*' read in admin_full_access, organization_admin and viewer_readonly. member_default, the everyone baseline, names neither, so a plain member has no sys_file read unless an application set grants it.
• The hydration. ObjectQL.resolveFileReferences (objectql/src/engine.ts) reads the referenced sys_file rows in one batch, as the caller. A refusal arrives as PermissionDeniedError (403) for the whole sub-read, measured on the real stack.
• The download door (service-storage/src/storage-routes.ts, GET /storage/files/:fileId and /url).
  • It reads the file by id under the system context, and never consults the caller's sys_file read.
  • authorizeDownload lets acl: 'public_read' through anonymously. A file with no scope and no field owner needs only a session.
  • Otherwise it goes to buildFileReadAuthorizer (storage-service-plugin.ts:1210):
    • the owner is allowed;
    • a field-owned file (ref_object + ref_id) is allowed if a declared fileAccessDelegate says so, else if the caller can read that record;
    • otherwise the file is allowed when any sys_attachment parent is caller-readable.
• Attachment rows. installAttachmentReadVisibility (service-storage/src/attachment-access-hooks.ts:758) ANDs a caller-readable-parent filter into every sys_attachment read, behind an object grant.
• The asymmetry. The same member can be allowed the bytes of a field-owned file and refused its name, size and type.

Governing text:

• ADR-0104 D3, verbatim: "Authorization: field-referenced files get parent-derived read checks, reusing the attachments authorizeFileRead verdict model — possession of a URL stops being possession of the bytes." The expanded form { id, name, size, mimeType, url } is "produced at read/expand time from the sys_file row".
• ADR-0110 D3: a fault must not wear the appearance of legitimate absent data. objectql: a file field reads "no file" for a record reader without sys_file read: the hydration lookup runs as the caller, and a refusal reads as absent data (split from #22590 item 1) #22593's loud half answers this.

选项 × 真实代价

业务含义直译:

• A:你能拿到文件,但信封上的名字被涂掉;要看名字得另外申请。
• B:你能拿到哪份文件,就能看到那份文件的名字。
• C:不仅看得到自己记录里的文件,还能直接翻整个文件柜里你能看的那些。

os-decision-facets

• ① 项目长远合理性:ADR-0104 D3 已写明字段引用的文件按父记录推导读权限,且展开形态从 sys_file 行产生。B 让水合与下载入口用同一条推导规则,一处授权语义。A 保留两套互相矛盾的规则。C 把推导规则下沉为 sys_file 的行级闸门,更彻底,但新增闸门与默认权限变更。
• ② 实际业务拉动:有实测拉动,即 hotclm 浏览器实测(Full browser test on 17.7.0 main: drive the whole contract lifecycle as every audience, in en and zh-CN, and report what a real user hits hotclm#87)中的合同申请人;main 上复现(objectql: a file field reads "no file" for a record reader without sys_file read: the hydration lookup runs as the caller, and a refusal reads as absent data (split from #22590 item 1) #22593 报告)。默认成员权限集不含 sys_file 读,所以任何没有额外授权的应用都会遇到。
• ③ 防 AI 犯错:A 要求每个(AI 写的)应用记得为每个带文件字段的对象额外授 sys_file 读,漏授静默降级。B 结构性地消除这个漏授点。C 同样结构性,但新增的默认授权本身是 AI 容易误解的面。
• ④ 创业阶段不扩散:B 只改引擎一个接缝,不加新闸门、不动默认权限集。C 新增行级闸门并改默认集,是新增门禁(默认否)。A 零改动。

Prior rulings read: sys_file read, file field authorization, attachment parent visibility → ADR-0104 D3 (parent-derived read for field files), #22431 (closed: an unowned file needs a session; public_read stays anonymous), #22455 (closed: the attachment write gate), #10702 (closed: sys_file metadata writability). Thread: #22593, #22590. None rules the hydration's read.

推荐

B:元数据的读权限与下载入口同源。

• 终态句: 两年后,一个文件「谁能看」只有一个答案:能读持有它的记录,就能看它的名字和内容;直接浏览文件表仍需要文件表权限。主流平台也是这样:Salesforce 中,对记录有读权限的用户能看到挂在记录上的文件(ContentDocumentLink 从父记录推导共享),不需要单独授予文件对象的权限。
• 自检: 只看①选 B;②③④ 是否翻转:否。
• 回退: A(现状加 fix(objectql): a refused sys_file read marks the file field refused instead of reading as no file #22620 的显式标记)可以接受;C 不推荐,它新增闸门。
• 置信缺口:
  • 「同一个人能下载却看不到名字」是读码结论,未用真实请求两端对照实测;
  • 行级收窄(对象可读、但部分行被过滤)的情形未测;
  • 是否有部署刻意依赖「成员看不到文件名」,测不到。

裁后执行

• 选 A: 不动读规则。fix(objectql): a refused sys_file read marks the file field refused instead of reading as no file #22620 的标记即终态。另立 objectui 卡渲染「详情无权查看」状态;本卡关闭。
• 选 B: domain:engine 立执行卡。resolveFileReferences 在对象读被拒时,对 ref_object/ref_id 与当前记录一致的文件 id,按 buildFileReadAuthorizer 的同一判定读取元数据。不一致的 id 保持 fix(objectql): a refused sys_file read marks the file field refused instead of reading as no file #22620 的拒绝标记。钉子覆盖字段所属、非所属与 public_read 三类,并做消融。Clause-②: yes,契约复审档复核。
• 选 C: 先由 domain:services 出 sys_file 行级闸门与默认权限集变更的方案卡,再定执行顺序。

Dedupe: MCP search_issues, repo-scoped, open and closed, two queries:

• 「sys_file read permission follow parent record file field metadata hydration attachment」 → 9 hits: objectql: a file field reads "no file" for a record reader without sys_file read: the hydration lookup runs as the caller, and a refusal reads as absent data (split from #22590 item 1) #22593 and runtime (17.7.0): file fields read "no file" for a record reader without sys_file read, flow run summaries report acted 0 while notifying, and the activity read pre-scan caps at 2000 rows fail-closed #22590 (this question's source), security(attachments): the attach / delete gate asks plugin-sharing's canEdit, which reads every controlled_by_parent object as public — a member with sys_attachment create/delete writes files on child records they cannot edit #22455, storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIED create grant, FILES_DISABLED) still leaves the uploaded sys_file committed with no join row #22547, storage(attachments): a committed sys_file whose attach is refused is never reaped — the lifecycle tombstones only files that lose their last join row, so a file that never gained one stays forever #22466, security(storage): the attachment gate's delete and update refusals name the parent record to a caller outside the floor's domain who cannot read it #21755, docs(permissions): attachments-access says Field.file stores a file URL in the column — since ADR-0104 D3 it stores a sys_file id #17406, [security-sensitive] sys_file mime_type/size are writable via the data API — may neutralize field accept/maxSize re-check (verify non-admin) #10702 and sys_comment has no record-level authorization: any org member reads and writes comments on records they cannot see #4630. None decides it.
• 「file download authorization ref_object ref_id field-owned file sys_file object permission member_default」 → 4 hits: storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIED create grant, FILES_DISABLED) still leaves the uploaded sys_file committed with no join row #22547, service-storage: a file with no scope and no field owner is downloadable by an anonymous caller who has its id; the download should require a signed-in caller, while acl: 'public_read' stays anonymous (ADR-0104) #22431, security(attachments): the attach / delete gate asks plugin-sharing's canEdit, which reads every controlled_by_parent object as public — a member with sys_attachment create/delete writes files on child records they cannot edit #22455 and docs(permissions): attachments-access says Field.file stores a file URL in the column — since ADR-0104 D3 it stores a sys_file id #17406. None decides it.

Dedupe words: sys_file metadata read parent-derived · file field hydration refused name size · download door vs hydration authorization asymmetry