Every time we add an operation, all authorizers, including OPA and Ranger, must adopt it. This acts as a contract between Polaris and the authorizer. I am less worried about privileges and more concerned about operation changes.
Besides that, what does it mean if GET_CATALOG_CONFIG(requires CATALOG_READ_CONFIG) passed, and GET_CATALOG_CONFIG_PROPERTIES(requires CATALOG_READ_PROPERTIES) didn't pass? The client may or may not receive partial results. And the client cannot tell whether those settings are absent or withheld. It may initialize successfully but behave differently because it didn’t receive the expected configuration. Yufei Yufei On Fri, Oct 30, 2026 at 2:15 PM Dmitri Bourlatchkov via dev <[email protected]> wrote: > > Hi JB and Yufei, > > You make good points! > > +1 to revising the config code to only put into responses what client > really need. > > GET_CATALOG_CONFIG_PROPERTIES is currently provided specifically to allow > admin users to restrict access to the wide properties bad. I would not mind > removing it once config responses are trimmed down. > > In the short term, PR #5246 is a tool admin user may find helpful for > managing existing servers. I support merging it now with the CHANGELOG > adjustment proposed by JB and further improving config responses later. > > Thanks, > Dmitri. > > > > On Fri, Oct 30, 2026 at 5:35 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi all, > > > > Thanks Yufei, I agree with the root problem. /v1/config returns the whole > > catalog properties map as defaults. That mixes client-facing settings (e.g. > > rest-page-size) with server-side ones (default-base-location, > > polaris.config.cleanup.on.catalog.drop). Gating all of it on > > CATALOG_READ_PROPERTIES is a blunt tool, and a client with only > > table-scoped or namespace-scoped grants can lose settings it needs. That > > was my concern with the earlier version of the PR (I shared on the thread). > > > > I see two separate questions: > > 1. What belongs in /v1/config? An explicit client-facing config, with > > server-only properties staying in the management API, is the cleaner > > long-term design. It changes what the endpoint returns and what clients > > see, so I would rather settle it in its own thread (more than inside > > #5246). I'm happy to sketch a proposal on that. > > 2. Should #5246 merge in the meantime? As Dmitri pointed out, the defaults > > keep the old behavior, so nothing breaks in this release. The PR gives > > operators and the Ranger/OPA authorizers a way to prepare. My preference is > > to merge it as is, on the condition that we don't flip any defaults before > > the client-facing config question is settled. I would also like that stated > > in the CHANGELOG, so nobody reads the flag's eventual default flip as a > > commitment. > > > > On GET_CATALOG_CONFIG_PROPERTIES: if we end up with an explicit > > client-facing config, we may no longer need it. Since it's an operation > > rather than a new privilege, the cost of keeping it for now is small. We > > can revisit it when the follow-up lands. > > > > Regards > > JB > > > > On Fri, Oct 30, 2026 at 6:34 AM Yufei Gu <[email protected]> wrote: > > > > > Sorry for the late reply. After reviewing #5246, I think we should > > > first decide which properties belong in /v1/config before adding > > > GET_CATALOG_CONFIG_PROPERTIES. > > > > > > The Iceberg REST spec describes this endpoint as providing > > > configuration for clients. Today, Polaris puts the entire catalog > > > properties map into defaults. That mixes client settings like > > > rest-page-size with server settings like default-base-location and > > > polaris.config.cleanup.on.catalog.drop. > > > > > > The PR makes those defaults all-or-nothing based on > > > CATALOG_READ_PROPERTIES. A client allowed to connect could therefore > > > lose settings it needs. > > > > > > Could we instead explicitly define the client-facing configuration and > > > return that, while keeping server-only properties in the management > > > API? With that separation, I don’t see a need for > > > GET_CATALOG_CONFIG_PROPERTIES. Authorization for the whole endpoint > > > can be discussed separately. > > > > > > Yufei > > > > > > Yufei > > > > > > > > > On Thu, Oct 29, 2026 at 8:55 AM Alex Dutra <[email protected]> wrote: > > > > > > > > Hi all, > > > > > > > > I also approved, +1 to merge. The PR is clean and we have a clear path > > > > forward regarding updates to Ranger. > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Tue, Oct 27, 2026 at 12:47 AM Dmitri Bourlatchkov <[email protected] > > > > > > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > I approved [5246] in GH. > > > > > > > > > > From my POV the PR offers a reasonable path towards tighter authZ > > > checks on > > > > > the /config endpoint. It does not break any APIs at this time. > > > > > > > > > > I propose merging it on Oct 28. > > > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > On Wed, Oct 21, 2026 at 9:17 PM Dmitri Bourlatchkov < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > I'm not sure how we (Polaris community) can check the behaviour of > > > (all) > > > > > > existing clients. > > > > > > > > > > > > PR [5246] provides ways to configure AuthZ grants in internal RBAC > > > and OPA > > > > > > such that Polaris' behaviour would be the same as before the > > change. > > > > > > CHANGELOG entries inform users of this change. The onus is on users > > > to > > > > > > validate their specific clients and use cases and configure the > > > system > > > > > > appropriately. Corresponding Ranger Authorizer changes are to > > follow > > > soon. > > > > > > > > > > > > Note that config defaults result in _old_ Polaris behaviour now. > > > Changes > > > > > > to default behaviours will be introduced only after the next > > > release. Users > > > > > > will have enough time to prepare. > > > > > > > > > > > > Heads up: PR [5246] approaches a mergegeable state from my POV. > > Only > > > minor > > > > > > merge conflicts remain. > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > > > > > On Fri, Sep 4, 2026 at 6:22 PM Yufei Gu <[email protected]> > > > wrote: > > > > > > > > > > > >> > 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 > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > >
