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 >
