Two `sys_file` insert doors bypass `StorageMetadataStore` and land `organization_id = NULL` — outside all four doors repaired so far

[claude]

What was measured

sys_file is tenant-scoped. It declares no tenancy key, so isTenancyDisabled() reads false and the kernel provisions organization_id on it — the reasoning is written out at the head of packages/services/service-storage/src/metadata-store.ts. Four doors on it have now been given the acting organization, one card at a time:

• createFile — insert door, multi-org: sys_file is never org-stamped — StorageMetadataStore.createFile inserts without a context while both callers hold the session #12745;
• createSession (sys_upload_session) — insert door, multi-org: sys_upload_session is never org-stamped either — StorageMetadataStore.createSession inserts without a context #12928;
• updateFile / deleteFile / updateSession / deleteSession — the four un-repaired halves, tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178, landed today in f087c376ff.

All four repairs run through StorageMetadataStore, which threads a StorageWriteContext into context.tenantId and lets the platform's insert-side chokepoint stamp the column.

Two other doors write sys_file rows without going through StorageMetadataStore at all, and neither carries an organization. They are outside every repair listed above.

site	function	what it passes
packages/services/service-storage/src/file-reference-lifecycle.ts:363	copyOwnedFile, an engine lifecycle hook	{ context: { ...SYSTEM_CTX } }
packages/services/service-storage/src/backfill-file-references.ts:186	backfill pass	{ context: SYSTEM_CTX }

SYSTEM_CTX in both files is { isSystem: true, [RAW_FILE_VALUES_CONTEXT_KEY]: true } — isSystem, and no tenantId.

Occurrences of the string organization_id, measured by content on 50cf2940b9, with the repaired file as the control:

file	occurrences of organization_id
packages/services/service-storage/src/file-reference-lifecycle.ts	0
packages/services/service-storage/src/backfill-file-references.ts	0
packages/services/service-storage/src/metadata-store.ts (repaired)	14

The control fires: the same probe over the repaired sibling returns 14, so the two zeros are measurements and not a broken grep. copyOwnedFile even records that it leaves ownership columns NULL deliberately ("Ownership columns are deliberately left NULL — the after-hook claims the copy for the slot that triggered it"), but the tenant column is not an ownership column and no after-hook claims it.

Why nothing catches it

1. buildDriverOptions (packages/objectql/src/engine.ts:3543) sees isSystem with no tenantId, so it emits no DriverOptions.tenantId — and it sets bypassTenantAudit = true.
2. SqlDriver.injectTenantOnInsert (packages/drivers/driver-sql/src/sql-driver.ts:11944) has no tenantId and stamps nothing. The row lands organization_id = NULL.
3. SqlDriver.auditMissingTenant (:11968) returns at its bypassTenantAudit guard, so the [tenant-audit] warning that names this exact defect ("writes will not be tenant-isolated") never fires.
4. The engine's own derivation, resolveSystemInsertOrganization, would refuse an unscoped insert loudly on a walled posture — but returns undefined at engine.ts:3765 because sys_file is in the platform namespace (isPlatformNamespaceObject).

So on a walled deployment a copied file row is org-less, silently, with the one diagnostic that exists switched off.

Consequence

The driver's tenant term is (organization_id = :tenantId OR organization_id IS NULL) (sql-driver.ts:11931), so a NULL-tenant sys_file row is reachable from every organization through the very update and delete doors #13178 has just scoped. The #13178 changeset states plainly that keeping org-less rows in reach is deliberate and load-bearing — it is what stops the pre-#12928 population being stranded. That reasoning is about a legacy population that ages out. These two doors keep minting fresh members of it.

Suggested shape, not a prescription

Route both doors through StorageMetadataStore so they inherit the repaired threading, or give each an explicit StorageWriteContext the way the four repaired doors take one. copyOwnedFile runs as a lifecycle hook and the triggering write's organization should be reachable at that point; the backfill is an operator pass and may need the organization supplied to it.

⚠️ Line numbers are as of 50cf2940b9 and rot. Re-locate by symbol — copyOwnedFile, injectTenantOnInsert, auditMissingTenant, resolveSystemInsertOrganization — rather than by line. This is the same rot warning #13178's own ruling carried about its census coordinates.

Measured while executing the stamper-gap measurement on #13497; recorded there as well, and filed separately so it does not live only in a comment. Not graded here: no priority or domain label, unassigned, for triage.

Generated by Claude Code

---

Generated by Claude Code

[claude]

分诊定级 · bug · security · p1 · domain:services · pm:queue

⚠️ 此前只带 pm:retriage(标签误用);本轮定级与摘标一次写完。

p1 —— 同 #13546 一个方向,且这是同一序列的第五、六扇门

sys_file 租户作用域,已被逐张卡修过四扇门(#12745 · #12928 · #13178 今日落 f087c376ff),而这两扇根本不过 StorageMetadataStore,因此在每一次修复之外:copyOwnedFile(引擎生命周期钩子)与 backfill 通道,两者都只带 SYSTEM_CTX。

⇒ 与 #13546 合看,今天一天在两个不同对象上各数出「墙外还有门」。⛔ 因此本单的必答项不是「修这两扇」,而是:

sys_file / sys_upload_session 的写入门是否已被穷举? 用枚举回答。四扇门是一张一张卡发现的 —— 这个发现方式本身就是缺陷:它保证下一扇门要等下一次事故。

⚠️ 一条本席实测的、卡自己不可能知道的事实

本卡把 #13178 列为其血统的一环。#13178 现在不可达(HTTP 404,两条传输一致) —— 见 #13548 与本席在其上的类测量。⇒ 引用它的读者拿不到那半段历史;本单正文里写下的三行血统,是目前唯一还能读到的记录。⛔ 谁接这张卡,请勿再往 #13178 上找上下文。

范围与存量

• 范围:两扇门接上 StorageMetadataStore(或等价地把 acting organization threaded 进去),⛔ 不重开前四扇的口径;
• 存量 NULL 行同 sys_http_delivery rows always land organization_id = NULL, so the deliberate cross-organization wall on redeliver() is reachable around for every row #13546:另立,走 needs-user-decision,不在本单顺手回填。

---

Generated by Claude Code