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
>
