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

Aperta
#11,470 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Felix-Gong ci sta già lavorando.

Dal 20/10/2026.

  • #11471 di @Felix-Gong — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
grpc, java

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
22.7k
Fork
12k
Merge medio
4g 20h
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/rocketmq

Tutte le issue di apache/rocketmq

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.