Hi Yufei, GET_CATALOG_CONFIG_PROPERTIES is not a privilege, it is an operation. It is needed for non-native authorizers (e.g. Ranger) because the SPI is formulated in terms of operations. Privileges are authorizer impl. details and may not be relevant in all cases (e.g. OPA does not have them AFAIK).
GET_CATALOG_CONFIG_PROPERTIES as an operation is different from the existing GET_CATALOG operation because it applies to a different API. It is conceivable that a user may have read access to catalog properties for the purpose of getting them via the /config endpoint, but not have access to catalogs themselves via the Management API. Cheers, Dmitri. On Wed, Sep 2, 2026 at 7:56 PM Yufei Gu <[email protected]> wrote: > It's a valid issue to fix. Thanks Vignesh! Looks like PR 5246 introduced a > new privilege GET_CATALOG_CONFIG_PROPERTIES. Is it necessary? Can we use > the existing privilege CATALOG_READ_PROPERTIES? I think > CATALOG_READ_PROPERTIES is meant to protect catalog properties. > > Yufei > > > On Fri, Aug 14, 2026 at 2:48 PM vignesh a <[email protected]> wrote: > > > Hi all, > > > > Following the review discussion on #5246 [1] GET /v1/config previously > had > > no AuthZ at all, so any authenticated principal that knew a warehouse > name > > could read the full catalog properties (defaults). Not great for > > multi-tenant setups. > > > > Proposal: > > > > 1. Always-on (no new privilege needed for the sensitive bit): > Soft-hide > > defaults unless the principal has CATALOG_READ_PROPERTIES (same idea > as > > management getCatalog). Prefix, endpoints, etc. are still returned so > > clients can bootstrap. > > 2. New privilege CATALOG_READ_CONFIG (op GET_CATALOG_CONFIG), > grantable > > now. Hard 403 on the whole endpoint only if: > > polaris.features."ENFORCE_CATALOG_CONFIG_AUTHORIZATION" = true Default > > is > > false, so operators can grant first (or rely on catalog-level content > > subsumption) and then turn enforcement on. > > 3. Later we flip the default to true and drop the flag. > > > > Why not hard-on in one shot: > > > > - Catalog-path checks don’t see table/ns-scoped grants → day-one > enforce > > can break least-privilege clients on upgrade. > > - Ranger still maps both ops to catalog-properties-read (no dedicated > > access type yet) → need time to update the service def + grants. > > > > Basically two-phase behaviour in one binary: permissions available now, > > enforcement when people are ready. > > > > I can also split GET_CATALOG_CONFIG into a follow-up PR if that is > > preferred — the flag makes that easy either way. > > > > Mainly interested whether default-false + later flip is acceptable, or if > > hard-on in a single release (with the breakage risk) is preferred. [1] > > https://github.com/apache/polaris/pull/5246 > > > > Thanks, Vignesh > > >
