[Bug] Proxy Admin authorization is skipped for methods missing from the permission map

未关闭
#11,470 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@Felix-Gong 已经在做这个了。

开始于 2026年10月20日。

  • #11471 来自 @Felix-Gong —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
停滞
技术栈
grpc, java

调研方向

Start with ProxyAdminAuthInterceptor and its METHOD_PERMISSIONS map, then read the existing interceptor test harness. Check how authorization behaves when a served method has no map entry, and add tests that compare the Admin RPC surface with the permission map. Done means unmapped methods are refused when authorization is enabled and a newly added RPC without a mapping fails CI; PR #11471 is already open.

由索引模型根据 Issue 内容生成。

描述

Search before asking

I checked open and closed issues and PRs for ProxyAdminAuthInterceptor, METHOD_PERMISSIONS, proxy.admin authorization and unmapped admin methods. The nearby open work is different: #11362 / PR #11363 changes which address the ACL is evaluated against, and #11178 / PR #11179 refuses to start when authorization is enabled without authentication. Neither covers what happens to a method that has no entry in the permission map.

What happened?

ProxyAdminAuthInterceptor binds every admin RPC to a proxy.admin.* resource through the static METHOD_PERMISSIONS map. The authorization branch is guarded by resourceAction != null:

ResourceAction resourceAction = METHOD_PERMISSIONS.get(method);
if (resourceAction != null && authzEnabled) {
    ... authorize against proxy.admin.<module> ...
}
return next.startCall(call, headers);   // unmapped methods land here

A method with no entry skips authorization completely and is served. With cluster authorization on, every mapped method gets a real ACL decision, but an unmapped one runs with authentication only — and the same is true in grpcAdminServerAuthEnable fail-closed mode, which only checks that authentication and authorization are enabled, not that this method is covered by them.

The admin server currently hosts only the Admin service and all 16 of its RPCs are mapped, so nothing is exploitable on develop today. But the surface grows from the rocketmq-apis side — the Admin service gained RPCs in three recent commits (#113, #115, #116) — and nothing cross-checks the proto against the map. The first future RPC merged without a hand-written entry becomes an authorization bypass by construction, including whatever mutation it introduces.

Expected behavior

When the cluster authorization switch is on, a served method that has no proxy.admin.* mapping should be refused (the class already documents fail-closed as its behavior mode) rather than served without a permission check. The map and the served surface should also be pinned against each other in tests, so adding an RPC without deciding its resource and action fails CI instead of shipping a silent hole.

Runtime

develop at 57c2dc0, JDK 11. Reproduced with the existing interceptor test harness — no broker or proxy required. On the current code, a call to an unmapped method name with authorizationEnabled=true reaches next.startCall(...); the new test fails exactly there.

主要语言
Java
星标
22.7k
派生
12k
平均合并
4 天 20 小时
30 天内合并 PR
11

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/rocketmq 的其他 Issue

查看 apache/rocketmq 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。