Sounds good to me. To be clear, once the operation is authorized, we will send catalog properties as before. While this is not perfect, given that additional properties may also be sent, we can close the loop by explicitly defining the client-facing configuration at the catalog level in a follow-up PR.
On Fri, Oct 30, 2026 at 3:25 PM Dmitri Bourlatchkov via dev < [email protected]> wrote: > Hi Yufei, > > How about we remove GET_CATALOG_CONFIG_PROPERTIES from PR 5246, but > keep GET_CATALOG_CONFIG? > > Note that GET_CATALOG_CONFIG bridges the existing authorization gap: all > endpoints except /config require authorization, but /config is not covered > as of 1.8.0. > > Thanks, > Dmitri. > > On Fri, Oct 30, 2026 at 6:06 PM Yufei Gu <[email protected]> wrote: > > > 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 > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >
