> 1) Always on: soft-hide catalog properties (defaults) unless the principal has CATALOG_READ_PROPERTIES. Prefix / endpoints still returned so clients can bootstrap.
The hiding may break existing IRC clients as well, given that clients won't be able to get any "serve default" and "server overrides" now in case of table-only permission. Can we double check this behavior change(hiding catalog properties) won't break existing IRC clients or cause a meaningful client-side behavior changes? Yufei On Fri, Sep 4, 2026 at 11:03 AM vignesh a <[email protected]> wrote: > Hi, > > Thanks all for the feedback > > On Yufei’s point: GET_CATALOG_CONFIG_PROPERTIES is an authorizable > operation, not a new privilege. The RBAC mapping reuses the existing > CATALOG_READ_PROPERTIES privilege (same idea as management getCatalog). > The separate operation is mainly for non-native authorizers (Ranger/OPA), > where the SPI is operation-based. Dmitri already covered that on-thread. > > On JB’s concern about CATALOG_READ_CONFIG: I agree /v1/config is the > Iceberg bootstrap call, and a hard 403 there is painful for principals > that only have table- or namespace-scoped grants. Catalog-path AuthZ does > not see those scoped grants, so day-one enforcement would break those > clients. That is why the PR keeps ENFORCE_CATALOG_CONFIG_AUTHORIZATION > default false - the privilege is grantable now, but the endpoint itself > is not hard-gated until an operator opts in. > > So today the PR is really two layers: > > 1) Always on: soft-hide catalog properties (defaults) unless the > principal has CATALOG_READ_PROPERTIES. Prefix / endpoints still > returned so clients can bootstrap. This is the actual disclosure fix. > > 2) Opt-in: hard-gate the whole endpoint behind CATALOG_READ_CONFIG when > the flag is true (for folks who want every REST path covered by AuthZ). > > JB’s suggestion to ship only (1) and drop (2) is a fair alternative if > the list prefers zero bootstrap risk. I’m fine either way: > > A) Keep both, flag default false, open a follow-up to flip the default > later (current PR shape), or > B) Narrow #5246 [1] to properties soft-hide only; revisit endpoint > hard-gate > in a later DISCUSS if we still want it. > > In my pov: A matches “all REST endpoints should eventually have AuthZ” > without breaking upgrades day one, but I’ll switch to B if that’s the > preferred consensus. > > WDYT?? > > https://github.com/apache/polaris/pull/5246 [1] > > Thanks, > Vignesh > > On Thu, 3 Sept 2026 at 20:06, Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi Vignesh > > > > It's actually a valid problem: CatalogConfigHandler.getConfig() > > doesn't authz at all today. It means any authenticated principal who > > guesses a warehouse name gets the catalog's properties. Clearly worth > > to fix. > > But, also, it returns PolarisEntity.getPropertiesAsMap() (should be > > user-visible properties), without internalProperties. So the exposure > > is admin-set config like default-base-location, not secrets. So, not > > super "criticial". > > > > I think it makes sense to "hide" defaults behind > > CATALOG_READ_PROPERTIES. It's similar to getCatalog path. This should > > be the only thing in the PR imho. > > > > I don't think the new CATALOG_READ_CONFIG property makes sense. > > /v1/config is the Iceberg bootstrap call, every client makes it before > > doing anything. Your PR leans on TABLE_READ_PROPERTIES, but that only > > works for catalog-level grants. A principal granted read one namespace > > or one table gets a 403 and cannot bootstrap at all. So I don't think > > it's a good idea, it's actually a unnecessary breaking change. > > > > Regards > > JB > > > > 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 > > >
