[Bug] Proxy Admin authorization is skipped for methods missing from the permission map
Maintainer thường phản hồi trong vòng 1 ngày
Đá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
- Lĩnh vực
- authorization, backend, security
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
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/rocketmq
-
[Bug] RemotingHelper.connect swaps the socket send and receive buffer configurationCó thể đã có người làm @amalsaidov đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
CompressionType.of fails under the Turkish localeCó thể đã có người làm @sharanggupta đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[rocketmq-client-python] TransactionMQProducer allocates an unused producer during initializationĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] notifyMasterOnline aborts the long-polling wake-up with a NullPointerException when an arrival drains a bucket firstCó thể đã có người làm @iloveeyjafjalla đã nhận 29 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
apache/rocketmq#11441 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Enhancement] FilterFactory duplicate-registration and unregister semantics lack testsCó thể đã có người làm @chennaji9 đã nhận 34 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
apache/rocketmq#11340 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của apache/rocketmq
Issue tương tự
-
bug emitter:client:csharp
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
microsoft/typespec#12572 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
GCC 15.2: -Wcast-qual warning - cast discards const qualifier from pointer target type (H5trace.c)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-area-label
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 2 ngày
-
area/ai area/backend component/zeebe kind/task
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
spAnser/reacharound#38 ·