analytics: 让 executeAggregate 桥携带 ExecutionContext(#3597 的纵深防御第二层)+ 两处残留无 scope 调用

[os-zhuang]

从 #3597 / #3601 拆出的后续项。#3601 已从 analytics 层堵死泄露(ObjectQLStrategy 现在把 read scope AND 进 filter),本 issue 处理第二层以及同一接缝上的两处残留。

1. 主项:让 executeAggregate 契约携带 ExecutionContext

#3597 的根因之一是 analytics→engine 的桥不传 context:

// services/service-analytics/src/plugin.ts:197-208
const rows = await engine.aggregate(objectName, {
  where: filter, groupBy, aggregations, timezone,   // ← 无 context
});

engine 侧本来是支持的 —— BaseEngineOptionsSchema(spec/src/data/data-engine.zod.ts:56-59)带 context: ExecutionContextSchema.optional(),engine.ts:3339 会 mergeReadContext。但 .optional() 意味着类型系统从不强迫调用方传,于是 analytics 桥就没传,进而命中 plugin-security 的无 principal fall-open(security-plugin.ts:775-781),把 engine 自己的 RLS 注入整个跳过。

为什么值得做(即便 #3601 已堵住泄露):

• 纵深防御。目前 analytics 的安全性单靠 strategy 自觉调用 getReadScope。security(analytics): ObjectQLStrategy 不消费 getReadScope — NativeSQL 回落后聚合查询无 RLS/租户谓词(#2852 修复未覆盖的另一半) #3597 正是"某个 strategy 忘了调"导致的;第 3 个 strategy 出现时会重演。context 一旦传下去,engine 侧 RLS 就是无条件兜底。
• 能解掉 fix(analytics): enforce read scope on the ObjectQL aggregate path (#3597) #3601 的 fail-closed 限制。fix(analytics): enforce read scope on the ObjectQL aggregate path (#3597) #3601 对"引用了带 scope 的联表对象"的查询选择拒绝,因为 engine.aggregate 的 where 只寻址基对象。若 engine 拿到 context,它可以按自己的对象图逐对象施加 RLS,这类查询就能正常跑而不是被拒。
• 契约层面 StrategyContext 目前只有预解析好的 read-scope map,不带 user/session,这本身就是个表达力缺口。

落点(需要动 packages/spec,会碰 api-surface 门,建议独立 PR):

• spec/src/contracts/analytics-service.ts:241-252 —— executeAggregate options 加 context?: ExecutionContext。
• StrategyContext —— 透传 ExecutionContext(或至少把 context 一路带到桥)。
• services/service-analytics/src/plugin.ts:197-208 —— 桥转发 context。
• analytics-service.ts 的 callCtx 已经拿到了 context,只是没往下带。

注意:这条不能替代 #3601。engine 侧 RLS 与 analytics 的 getReadScope 是两套解析(前者走中间件,后者走 security.getReadFilter),两者都保留才是纵深防御;而且没装 plugin-security 的部署只有 analytics 这一层。

2. 残留:fetchRecordLabels 走的是同一条无 scope 的桥

// services/service-analytics/src/plugin.ts:348-364
const rows = await executeAggregate(targetObject, {
  groupBy: ['id', displayField],          // ← 每条记录一行
  aggregations: [{ field: 'id', method: 'count', alias: '_c' }],
  filter: { id: { $in: ids } },           // ← 无 read scope、无 context
});

groupBy: ['id', displayField] 等于逐记录返回真实显示名 —— 粒度上是行级而非聚合级。

当前是否越权:否。 #3601 之后聚合本身已加 scope,喂进来的 ids 已被限制在调用者可见范围内。所以这是潜在债而非活漏洞:一旦 ids 的来源变宽(新调用方、新 strategy),它会立刻变成行级泄露,且没有任何一层会拦。

建议:要么让它也吃 read scope,要么在 #1 落地后靠 context 兜底。

3. 残留:ObjectQLStrategy.generateSql 预览不含 scope

objectql-strategy.ts:117-149 生成的展示性 SQL 完全没有 WHERE 子句,所以 /analytics/sql 的预览与实际执行的语义不符(实际执行在 #3601 后是加了 scope 的)。

不构成泄露(该 SQL 不执行,只用于展示),但会误导排查者。修的话需要把 FilterCondition 编成 SQL —— read-scope-sql.ts 的 compileScopedFilterToSql 已有能力,只是 ObjectQL 的 generateSql 没有 NativeSQL 那套 alias 体系,需要小心。优先级最低。

---

🤖 Generated with Claude Code

[os-zhuang]

更正 + 主项重估(基于引擎侧独立追查)

写残留 1 的端到端测试时,对引擎侧做了一轮独立 trace,证伪了本 issue 主项最强的那条理由。诚实更正如下。

我之前写错的地方

本 issue 正文和 #3601 的 assertJoinedScopesEnforceable 注释里说"engine 经 lookup 遍历被联对象 / 传 context 可解掉这条 fail-closed 限制"。这是错的。

确定的事实(带行号):

• engine.aggregate(engine.ts:3332-3384)只用 {object, where, groupBy, aggregations} 建 AST,从不解析点号、从不填 joins、从不展开 lookup。对比 find 有 expandRelatedRecords 会对被引用对象重跑 RLS/FLS(engine.ts:2007-2133)—— aggregate 一次都不调。
• SQL driver 的 aggregate(sql-driver.ts:1562-1622)方法里没有任何 .join();joins:true 是广告了但没实现的能力位。
• 安全中间件的 RLS 注入(security-plugin.ts:1536)只对 opCtx.object(基对象)算一次谓词,不遍历 join 图。

对主项的影响:建议 won't-do

主项(把 ExecutionContext 穿进 executeAggregate → engine.aggregate 作纵深防御第二层)原本有两个理由:

1. 解锁联表(去掉 fix(analytics): enforce read scope on the ObjectQL aggregate path (#3597) #3601 的 fail-closed 拒绝) → 已证伪。引擎无 join,传 context 变不出被联对象,也没有"被联对象的行"可供 RLS 加/漏。
2. 基对象的冗余纵深防御 → 仅剩这个:引擎中间件拿到 context 后,把基对象的 RLS 再注入一遍,和层 1(analytics getReadScope)已加的同一条谓词。

净收益只剩"同一条基对象谓词加两遍",还背着:

• double-scoping 发散风险:公开 getReadFilter(层1)与中间件 computeRlsFilter(层2)若在 sharing/owner 放宽上推导不一致,交集会少算行(正确性回归,方向安全但结果错);
• spec 改动(3 处 executeAggregate 类型加 context)撞 api-surface 门 + changeset;
• 若为避免双加而改成互斥,又会重新引入顺序依赖 —— 我们刚在 fix(analytics): make the read-scope auto-bridge order-independent + first real e2e RLS gate (#3618) #3619 修掉它。

建议:主项关成 won't-do。 层 1(#3601 + #3619 后:两条 strategy 都消费、顺序无关、fail-closed、预解析)是唯一充分的控制,当前无活漏洞。引擎层第二条带子有意不接的理由记在此:(i)它连 join 都 scope 不了,(ii)层 1 已覆盖,(iii)双加有发散风险。

附带暴露的既有功能缺口(与 RLS 无关,建议单独 issue)

既然引擎 aggregate 无 join:跨对象聚合在 ObjectQL 回退路径上本就不工作 —— ObjectQLStrategy 把 account.region 原样当 groupBy 字符串传给引擎,SQL driver 上报错(account 不在 FROM),in-memory 上 row['account.region'] 平键取值恒 undefined → 全塌进一个 (null) 桶,静默算错。跨对象数据集只在 NativeSQLStrategy(手编 LEFT JOIN)上工作;一旦 NativeSQL 声明失败(日期分桶 / in-memory / federated)回退到 ObjectQL,跨对象查询就坏。#3601 的 guard 只是把"被联对象带 scope"这一种情形从"SQL 报错/静默垃圾"换成"一条干净的安全拒绝"——行为改善,但注释措辞错。值得一个确认性测试 + 单独 issue。

三项现状

• 残留 1(取名读加被引用对象 scope):真实窄泄露,已修 → PR fix(analytics): scope the dimension-label lookup to the referenced object's RLS (#3602 residual 1) #3639。
• 主项(穿 context):建议 won't-do(见上)。
• 残留 2(generateSql 补 WHERE):纯展示、不执行、不泄露,优先级最低,未做。

若同意,本 issue 可在 #3639 合并后关闭(残留 1 已修,主项 won't-do,残留 2 可另开轻量 issue 或并入)。

[os-zhuang]

残留 1 已修并合并:PR #3639(commit 415254c),含真栈 dogfood e2e。三项现状:①残留 1 ✅ 已修;②主项 建议 won't-do(见上评论);③残留 2 未做(纯展示)。待你决定是否整体关闭。