The proposed behavior makes sense. Returning a list of catalogs only a caller can access feels more aligned with least privilege and with how most users would expect catalog discovery to work.
Implementation does not seem particularly difficult. The existing admin behavior could remain unchanged, while non-admin callers receive a filtered list based on catalog level authorization checks similar to those already performed by getCatalog(). There are minor perf concerns, but I think it should be acceptable in general. To me, the bigger question is agreeing on the API semantics rather than the implementation itself. Overall, I'm supportive of the change. Yufei On Thu, Jun 4, 2026 at 5:05 PM Dmitri Bourlatchkov <[email protected]> wrote: > It looks like this reply got disconnected from the original thread. > > Posting a link to it for reference: > https://lists.apache.org/thread/w58zrjt6jpq33mv9lvqzndqc6no5l7xb > > Cheers, > Dmitri. > > On Sun, May 31, 2026 at 12:15 PM venkateshwaran cholan < > [email protected]> wrote: > > > Hi all, > > > > Thanks Grace for putting together the proposal, and thanks everyone for > the > > detailed feedback and discussion so far. > > > > Dimas pointed me to this discussion from #4573, and I wanted to share an > > observation after tracing the current implementation on main. > > > > The discoverability gap there (catalog-role access works for getCatalog > and > > Iceberg operations, but listCatalogs requires root CATALOG_LIST) looks > like > > one concrete case of the broader visibility model discussed here, > > particularly if CATALOG_READ_PROPERTIES ends up being the selected > > visibility privilege for catalogs. > > > > listCatalogs() still gates on > > authorizeBasicRootOperationOrThrow(LIST_CATALOGS) against the root > > container, while getCatalog() authorizes per catalog. That matches the > > asymmetry described in the issue. > > > > I agree that authorizer-layer filtering is preferable to a > > listCatalogs-only special case so default RBAC, OPA, and other > authorizers > > stay consistent. > > > > One thing I am still unclear on for LIST_CATALOGS: the proposal's scope > > short-circuit does not apply because there is no scope container (unlike > > LIST_NAMESPACES / LIST_TABLES). > > > > For #4573-style discoverability, it seems we would want callers without > > root CATALOG_LIST to get a filtered list instead of 403. > > > > Separately, when entity filtering is enabled, should callers with root > > CATALOG_LIST still get a filtered list, or is root CATALOG_LIST intended > to > > mean "see all catalogs" with filtering only handling the discoverability > > case? > > > > Happy to help with regression coverage either way. For example, an authz > > test where a principal has catalog-scoped CATALOG_READ_PROPERTIES via a > > catalog role but no root CATALOG_LIST: getCatalog succeeds and > listCatalogs > > fails today, documenting the gap until filtering lands. > > > > Thanks, > > Venkateshwaran > > >
