[gRPC][PII] 4xx errcode PublicDetails 含 subjectID 经 #2482 进入 gRPC ErrorInfo.Metadata wire

[ghbvf]

现状（证据 + 三维根因）

PR #2495（#2482）让 4xx *errcode.Error 的 PublicDetails 经 clientStatusWithDetails 投到 gRPC google.rpc.ErrorInfo.Metadata。adapters/postgres/session_store.go:166,203,329 用 errcode.WithDetails(errcode.PublicString("subjectID", …)) 把 subject 标识放进 4xx PublicDetail —— 这些错误若经 gRPC 返回，subjectID 现进入 ErrorInfo.Metadata["subjectID"]（此前 gRPC message-only 会丢弃；HTTP 路径一直已下发）。

• 代码根因：session_store 把 subjectID 标为 Public（4xx 下发面），[gRPC] 4xx errcode PublicDetails 未带到 google.rpc.Status.Details（wire 详情 HTTP/gRPC 不对等） #2482 忠实转发「声明为 public」的 detail。
• 架构根因：PublicDetail 是「4xx-safe」契约面；是否允许 subject 标识进 wire 是 errcode-usage 决策（在 session_store），非 interceptor 决策（interceptor 只能全转发或做 denylist hack）。
• 历史根因：subjectID-as-PublicDetail 自 session_store 引入即在 HTTP wire；[gRPC] 4xx errcode PublicDetails 未带到 google.rpc.Status.Details（wire 详情 HTTP/gRPC 不对等） #2482 仅使 gRPC 达到 parity。

影响

subjectID 是调用方自身输入的回显（NotFound「找不到该 subject 的 session」），非第三方泄漏；HTTP 已有同等暴露。但在 MDM/零信任下，错误响应回显身份标识是可审视的最小暴露面。安全 reviewer 结论：业务 4xx（errcodeDomain）与 deny ErrorInfo（denyReasonDomain，禁 subject）分域，可接受；登记以便有意识审计，不阻塞 #2495。

修复方向（三级方案种子）

• minimal：确认 subjectID 回显属可接受业务语义 → 文档登记并关单。
• thorough：审计所有 PublicString("subject"/"subjectID") 用法，对身份标识改用 WithInternal（仅服务端日志）或 hash，避免进 4xx wire。
• refactor：errcode 增 PII-tagged detail 类别，wire 投影按 tag 过滤（HTTP/gRPC 共用 PII 策略，单源）。

Files

• adapters/postgres/session_store.go:166,203,329
• framework/runtime/grpc/interceptor/errcode_mapping.go（clientStatusWithDetails / publicDetailsToMetadata）

Source

PR #2495 review（安全维度 OOS finding）。Discovered via /ship #2482。