Hey Yufei, Thanks for reviewing. Let me reply to your comments:
1. Trust boundary: I think whether a client can be trusted to provide > a view chain should be controlled by the system admin. We may not need > enforce it in Polaris SPI or API. I'm not sure what you mean exactly by system admin so I'm taking a guess here. The proposal doesn't mandate Polaris and the authorizer to define "trust"; instead, it leaves it to the person setting up the platform and granting client access (the system admin?) to define which clients are trustworthy, and by extension how trust is represented and how the authorizer implementation can assert that trustworthiness. 2. Chain resolution: Do we expect Polaris to resolve the view chain, > or leave it to individual authorizers? For example, v3 references v2, > v2 references v1, and v1 references t1. I assume the authorizer needs > to evaluate the entire chain to determine the effective authorization > context. I'd prefer Polaris to only handle basic parsing and > validation, and leave chain resolution and interpretation to > individual authorizers, but open to suggestions. It should have been mentioned in the proposal but Polaris handles parsing the reference chain and splitting it into individual objects, along with some basic validation (duplicates, max depth). The authorizer is left with the actual evaluation because as you said, authorizers could interpret the chain differently (one being that the chain is just ignored, which is the current behavior of all authorizer extensions). 3. Do we need to introduce the new privileges and role switching as > part of this proposal? I don't think this applies to the SPI part, only to the builtin authorizer implementation part. If discussing the builtin authorizer is distracting and people are okay focusing only on the SPI changes, I can totally split the proposal into two separate issues. Overall, I'm supportive of part 1. I'd prefer to keep the SPI generic > and leave the authorization details to individual authorizers. Hopefully this is the case and the draft PR for the SPI change should already reflect that. Cheers, Laurent On Wed, Nov 4, 2026 at 5:23 PM Yufei Gu <[email protected]> wrote: > Hi Laurent, > > Thanks for putting together the proposal! > > The overall direction makes sense to me. I agree that exposing the > referenced-by chain through the authorization SPI is a reasonable > first step, so different authorizers can implement their own > authorization policies. > > A few thoughts: > > 1. Trust boundary: I think whether a client can be trusted to provide > a view chain should be controlled by the system admin. We may not need > enforce it in Polaris SPI or API. > > 2. Chain resolution: Do we expect Polaris to resolve the view chain, > or leave it to individual authorizers? For example, v3 references v2, > v2 references v1, and v1 references t1. I assume the authorizer needs > to evaluate the entire chain to determine the effective authorization > context. I'd prefer Polaris to only handle basic parsing and > validation, and leave chain resolution and interpretation to > individual authorizers, but open to suggestions. > > 3. Do we need to introduce the new privileges and role switching as > part of this proposal? > > Overall, I'm supportive of part 1. I'd prefer to keep the SPI generic > and leave the authorization details to individual authorizers. > > On Wed, Nov 4, 2026 at 12:20 PM Laurent Goujon via dev > <[email protected]> wrote: > > > > Hi all, > > > > The Iceberg REST spec has an optional `referenced-by` query parameter on > > loadTable, loadView and loadCredentials (apache/iceberg#13810). When an > > engine loads a table or view while evaluating a view, it can pass the > chain > > of views it went through, outermost first. It was added to make definer > > views possible. Polaris accepts the parameter but drops it today, so no > > authorizer can act on it. > > > > I wrote a proposal and opened a draft PR for the first part: > > > > - Proposal: https://github.com/apache/polaris/issues/5979 > > - Draft PR (part 1): https://github.com/apache/polaris/pull/5980 > > > > The proposal has two parts: > > > > 1. SPI. Pass the parsed chain to authorizers through a new > > `SingleTargetAuthorizationIntent#referencedBy()` accessor. A chain that > > cannot be parsed, is deeper than a configurable limit (10 by default) or > > repeats an entry is rejected with a 400. The chain is added to the load > > events. Existing authorizers (built-in, OPA, Ranger) are unchanged, and > the > > PR does not change any decision. > > 2. Built-in authorizer. An administrator binds a view to a catalog role > (a > > new `CATALOG_ROLE_EXECUTE_AS` privilege, with the view as the grantee), > and > > a new catalog privilege marks the callers that may assert a chain. The > > built-in authorizer then evaluates the chain, switching to the bound role > > at each bound view. This part is not in the PR. > > > > Since part 1 changes an extension point, I would like to agree on it here > > before taking the PR out of draft. > > > > Re part 2: the proposal includes it so that part 1 comes with a proof of > > concept for how an authorizer would use the chain. I can also work on a > PR > > for it, or we could focus on a different authorizer instead (I'm open to > > that). > > > > Thanks, > > Laurent >
