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
