Hi All, Many thanks to all who participated in this feature!
I merged [5246] and opened a minor optional follow-up adjustment for the warning message in [6007]. It's mainly following Aushes comments in [5246]. [5246] https://github.com/apache/polaris/pull/5246 [6007] https://github.com/apache/polaris/pull/6007 Cheers, Dmitri. On Fri, Nov 6, 2026 at 2:04 PM Yufei Gu <[email protected]> wrote: > Thanks for the update. > > I have approved the PR yesterday. I think it's OK to merge, but please > check for any other blockers before merging. > > Yufei > > On Fri, Nov 6, 2026 at 10:55 AM Dmitri Bourlatchkov via dev > <[email protected]> wrote: > > > > Hi All, > > > > Heads up on the status of [5246]: > > > > * As far as I can tell, Vignesh addressed all comments related to RBAC > > grants (from Yufei and Dennis). > > > > * Ayush posted some comments about subsuming permissions acorss entities. > > Unfortunately, I do not think the current RBAC model supports that. In > the > > current codebase we can only provide reasonable subsuming behaviour for > > catalog-level grants. I personally think it is acceptable. > > > > * Ayush mentioned the inconvenience of the default production check > > warning. I added a commit to suppress that warning for non-internal > > authorizers. > > > > * The internal RBAC for getConfig should be functional in this PR and can > > be enabled by end users to remove the production check warning. > > > > * Follow-up issues have been filed for implementing the new check in > Ranger > > and for enabling the new feature flag by default later. > > > > All of the above is reflected in GH comment threads. > > > > Please do another review pass of the PR. I hope people who raised > concerns > > before could acknowledge the resolution of those issues by approving the > PR > > in GH. As I mentioned before, I think it is valuable to include it in > 1.9.0. > > > > Thanks, > > Dmitri. > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > On Thu, Nov 5, 2026 at 3:35 PM vignesh a <[email protected]> wrote: > > > > > Hi Yufei, > > > > > > Sorry for the delay on the SUPER thread on #5246 [1]. > > > > > > POLICY_* / SEMANTIC_MODEL_* and the remaining Iceberg table-update > > > privileges are on CATALOG_READ_CONFIG SUPER now, so catalog-level > > > grants can still bootstrap /v1/config. Skipping TABLE_READ_METRICS; > > > it isn't enforced yet. > > > > > > Namespace-scoped grants still 403 when the flag is on; that's > > > documented. The flag stays default false. > > > > > > Thanks, > > > Vignesh > > > > > > [1] https://github.com/apache/polaris/pull/5246 > > > > > > On Fri, 6 Nov 2026 at 00:31, Yufei Gu <[email protected]> wrote: > > > > > > > JB, Dennis, and I have raised several concerns in the > > > > thread( > https://github.com/apache/polaris/pull/5246/changes#r4383768595), > > > > and it looks like they are still unresolved. The original comments > > > > date back to Oct 26, but we haven't received any responses or > > > > follow-ups for over a week. > > > > > > > > Dmitri, could you please check with the author and help get these > > > > concerns addressed? > > > > > > > > Yufei > > > > > > > > On Thu, Nov 5, 2026 at 6:15 AM Dmitri Bourlatchkov via dev > > > > <[email protected]> wrote: > > > > > > > > > > Hi Yufei, > > > > > > > > > > I believe the comment thread you mentioned [1] has been resolved > for > > > > > relevant grants. > > > > > > > > > > If you think something is missing, please respond with a more > specific > > > > > rationale. > > > > > > > > > > PR [5246] has several approvals. As I mentioned before, I think it > is > > > > > essential to have it in 1.9.0 to prepare users for future migration > > > > toward > > > > > better authorization coverage. Delaying this PR by another release > will > > > > > effectively delay authorization improvements on the user side by > two > > > (!) > > > > > releases. > > > > > > > > > > Please note that the main purpose of this PR is establishing the > new > > > > AuthZ > > > > > operation and a feature flag. The new check is _not_ enforced by > > > default. > > > > > Any remaining changes for Ranger and internal RBAC grants can be > done > > > on > > > > > main after 1.9.0. > > > > > > > > > > I propose merging it before 1.9.0 is branched, ideally today or > > > tomorrow. > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > > > [1] > https://github.com/apache/polaris/pull/5246/changes#r4383768595 > > > > > > > > > > On Wed, Nov 4, 2026 at 6:52 PM Yufei Gu <[email protected]> > wrote: > > > > > > > > > > > I'd suggest not merging when there are comments needed to be > > > resolved, > > > > > > here is an open comment: > > > > > > https://github.com/apache/polaris/pull/5246/changes#r4383768595 > > > > > > Yufei > > > > > > > > > > > > On Wed, Nov 4, 2026 at 3:45 PM Dmitri Bourlatchkov via dev > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > Given an extensive review period, I propose merging [5246] on > Nov > > > 6. > > > > > > > > > > > > > > Note: this PR does _not_ introduce any behaviour changes. It > only > > > > > > prepares > > > > > > > options for stricter authZ in the future. > > > > > > > > > > > > > > Please reply to this thread or comment in GH if you have any > > > > concerns. > > > > > > > > > > > > > > Thanks, > > > > > > > Dmitri. > > > > > > > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > > > > > > > On Mon, Nov 2, 2026 at 10:16 AM Dmitri Bourlatchkov < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Vignesh, > > > > > > > > > > > > > > > > Thanks for promptly addressing the feedback! > > > > > > > > > > > > > > > > I think PR [5246] approaches a mergeable state. > > > > > > > > > > > > > > > > Given that it introduces a migration action for users, which > is > > > > > > optional > > > > > > > > in the current code, I think it makes sense to include the PR > > > into > > > > the > > > > > > > > upcoming 1.9.0 release. This will enanle working on flipping > the > > > > flag > > > > > > In > > > > > > > > the following release. > > > > > > > > > > > > > > > > Yufei, Dennis: Please take a look at the latest PR state. > > > > > > > > > > > > > > > > [5246] https://github.com/apache/polaris/pull/5246 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Oct 31, 2026 at 12:11 PM vignesh a < > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> Hi all, > > > > > > > >> > > > > > > > >> Thanks Yufei, Dmitri and JB. I've restacked #5246 [1] > > > > > > > >> > > > > > > > >> Dropped GET_CATALOG_CONFIG_PROPERTIES. That takes out the > second > > > > > > > >> authorizer op and the partial-result case Yufei called out, > > > where > > > > a > > > > > > > >> client can't tell absent settings from withheld ones. > > > > > > > >> > > > > > > > >> Kept GET_CATALOG_CONFIG behind > > > > ENFORCE_CATALOG_CONFIG_AUTHORIZATION > > > > > > > >> (default false), as Dmitri asked. That covers the /config > AuthZ > > > > gap as > > > > > > > >> of 1.8.0, and existing deployments keep today's behaviour. > > > > > > > >> > > > > > > > >> Once that check passes, the response still returns catalog > > > > properties > > > > > > > >> as it does today. > > > > > > > >> > > > > > > > >> CHANGELOG says the default is not flipping until the > > > client-facing > > > > > > > >> config follow-up is settled, as JB asked. Client-facing vs > > > > server-only > > > > > > > >> properties can stay in its own thread. > > > > > > > >> > > > > > > > >> PR is updated now. PTAL > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > >> *Vignesh* > > > > > > > >> > > > > > > > >> [1] https://github.com/apache/polaris/pull/5246 > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >
