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 > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > >
