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

Đang mở
#11,470 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Felix-Gong đang làm issue này rồi.

Từ ngày 20/10/2026.

  • #11471 của @Felix-Gong — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
grpc, java

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
22.7k
Fork
12k
Merge trung bình
4 ngày 20 giờ
Pull request đã merge (30 ngày)
11

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/rocketmq

Tất cả issue của apache/rocketmq

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.