Hi Venkateshwaran, Thanks for reviewing the proposal. These are great questions, let me address each:
For #1, the proposal implicitly excludes LIST_CATALOGS from the scope because it is part of the Polaris management API. However, after looking into the grant model, the short-circuit can also be applied to LIST_CATALOGS when CATALOG_READ_PROPERTIES is granted on the root. The ROOT entity serves as the scope container, and the default authorizer's path-walking hasTransitivePrivilege finds the grant without requiring any special handling. There’s one caveat: OPA authorizer would need to handle CATALOG_READ_PROPERTIES checked against a ROOT-typed entity to benefit from the short-circuit. For #2, in my opinion, when entity filtering is enabled, CATALOG_LIST should no longer be used for LIST_CATALOGS, because the entity filter is supposed to enhance both discoverability and fine-grained access to list operations. The main backward-compatibility risk is that users who currently have CATALOG_LIST at root but not CATALOG_READ_PROPERTIES will see empty results instead of all catalogs when filtering is enabled. This requires us to keep the opt-in and opt-out available for a longer period of time, with clear documentation and a migration strategy so admin can audit and update grants before enabling the feature. I'll update the design doc shortly and revisit the draft PR. Thanks, Grace > On May 31, 2026, at 12:14 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
