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