No problem, I know we’ve been going back on this one for a while so it’s been a bit confusing
On Fri, Jan 30, 2026 at 6:07 PM Daniel Weeks <[email protected]> wrote: > Thanks for the clarification Russel and Prashant. > > My initial concern was that we were introducing the definer/invoker > constructs and assuming the trust relationship through the spec language, > but it looks like we reference that in the PR description and discussion > but not the spec language itself. At some point we need to address the > intended usage here because the primary usage was within the context of the > trust relationship (other usage like auditing seems a secondary > motiviation). > > Apologies for the confusion and I'll happily retract my -1. > > -Dan > > > > On Fri, Jan 30, 2026 at 2:29 PM Prashant Singh <[email protected]> > wrote: > >> Thank you for the feedback Ryan, I will update the separator in this case >> to be the namespace separator ! I will do more research on other feedback. >> >> Thanks for the feedback Dan, >> >> Agree with Russell here, I believe the whole reason why we wanted to have >> a referenced-by chain is to give the catalog the complete context of how to >> Authorize and since IRC don't go in the world of AuthZ >> we thought just let the catalog do what they wanna do with referenced-by, >> we are *not* defining actions what we want the catalog to take in the >> spec. >> We have additionally discussed this in the DISCUSS thread too [1]. >> >> Definitely for the E2E picture for making this work we need *Trusted >> Engine,* *OWNER* privilege and then *AuthZ* to correctly give read >> access to the table, but these are purely Catalog side constructs based on >> AuthZ. >> The simplest rationale of allowing this to be sent from the client to >> server apart from DEFINER view is to help in audit as well. >> >> Please let us know if it helps address your concerns. >> >> [1] https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >> >> Best, >> Prashant Singh >> >> On Fri, Jan 30, 2026 at 1:03 PM Russell Spitzer < >> [email protected]> wrote: >> >>> @Daniel I believe we talked about this only working in a situation where >>> the client and catalog have already pre-established a trusted relationship. >>> This was brought up again on the PR a few days ago, >>> https://github.com/apache/iceberg/pull/13810#issuecomment-3816022525 >>> and Prashant posted links again to the original thinking there. >>> >>> Wouldn't this mean that you just can't give access to a client which can >>> make arbitrary calls against your catalog? >>> >>> If a client can fake a request to the catalog, then why wouldn't it just >>> ask for the table through the view directly, get the files (ignoring the >>> view) and then read the table? >>> >>> On Fri, Jan 30, 2026 at 2:30 PM Daniel Weeks <[email protected]> >>> wrote: >>> >>>> I'm going to have to update my comment to -1. >>>> >>>> Based on some of the discussion in the PR, I went back and reviewed the >>>> discussion and I don't think this approach works based on some comments I >>>> made in the recording (link with timestamp >>>> <https://youtu.be/orAXA5e9pmU?si=CjIEQk__dcTWcdEi&t=1438> and again >>>> here <https://youtu.be/orAXA5e9pmU?si=tvpIN6ytIu2JU_fj&t=1902>). >>>> >>>> The main issue I see is that we're not enabling a secure way to do this >>>> because we cannot trust the client to provide the surrounding view. What >>>> would prevent a client from just addressing a defender view in a load table >>>> and accessing data the invoker should not have access to? >>>> >>>> I feel like there are security implications here that we haven't >>>> properly addressed. >>>> >>>> -Dan >>>> >>>> >>>> >>>> On Fri, Jan 30, 2026 at 8:52 AM Ryan Blue <[email protected]> wrote: >>>> >>>>> -1 for now (will probably change) >>>>> >>>>> I think that there is a problem in that a dot is used to separate the >>>>> namespace (which uses namespace separator) from the table name. If my >>>>> namespace separator is `|` then it would require `name|space.table`. Why >>>>> not use the same separator between the namespace and table name? If we use >>>>> `.` then the last namespace part cannot have a `.`, which is an odd >>>>> restriction. >>>>> >>>>> On Thu, Jan 29, 2026 at 12:07 PM Daniel Weeks <[email protected]> >>>>> wrote: >>>>> >>>>>> +1 (binding) >>>>>> >>>>>> Minor comments on the Spec PR. I'm assuming everyone is voting >>>>>> specifically on the spec changes, but just want to clarify >>>>>> (implementation >>>>>> PR will go through normal review process). >>>>>> >>>>>> -Dan >>>>>> >>>>>> On Thu, Jan 29, 2026 at 9:38 AM Steve <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> +1 (non-binding) >>>>>>> >>>>>>> On Thu, Jan 29, 2026 at 12:57 AM Alexandre Dutra <[email protected]> >>>>>>> wrote: >>>>>>> > >>>>>>> > +1 (non-binding) >>>>>>> > >>>>>>> > Thanks, >>>>>>> > Alex >>>>>>> > >>>>>>> > Le jeu. 29 janv. 2026 à 08:19, Bharath Krishna < >>>>>>> [email protected]> a écrit : >>>>>>> >> >>>>>>> >> +1, that was a missing piece for view authorization! >>>>>>> >> >>>>>>> >> On 2026/01/29 07:03:31 roryqi wrote: >>>>>>> >> > +1, excited to see this. I am working on related work about >>>>>>> Apache Gravitino. >>>>>>> >> > >>>>>>> >> > Christian Thiel <[email protected]> 于2026年1月29日周四 >>>>>>> 14:50写道： >>>>>>> >> > > >>>>>>> >> > > +1 (non-binding) >>>>>>> >> > > >>>>>>> >> > > Gábor Kaszab <[email protected]> schrieb am Do. 29. >>>>>>> Jan. 2026 um 07:22: >>>>>>> >> > >> >>>>>>> >> > >> +1 (nb) >>>>>>> >> > >> >>>>>>> >> > >> Gábor >>>>>>> >> > >> >>>>>>> >> > >> On Thu, 29 Jan 2026, 00:02 Adnan Hemani via dev, < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>> >>>>>>> >> > >>> +1 (non-binding) >>>>>>> >> > >>> >>>>>>> >> > >>> On Wed, Jan 28, 2026 at 10:17 AM Steven Wu < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>> >>>>>>> >> > >>>> +1 >>>>>>> >> > >>>> >>>>>>> >> > >>>> On Wed, Jan 28, 2026 at 8:02 AM Russell Spitzer < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>> >>>>>>> >> > >>>>> +1 >>>>>>> >> > >>>>> >>>>>>> >> > >>>>> On Wed, Jan 28, 2026 at 10:01 AM Eduard Tudenhöfner < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>> >>>>>>> >> > >>>>>> +1 >>>>>>> >> > >>>>>> >>>>>>> >> > >>>>>> On Tue, Jan 27, 2026 at 6:29 PM Prashant Singh < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> Hello everyone ! >>>>>>> >> > >>>>>>> The namespace separator for nested namespaces >>>>>>> discussion is converged (thanks a ton Eduard) >>>>>>> >> > >>>>>>> I additionally also added wording for the nested views >>>>>>> per the feedback. >>>>>>> >> > >>>>>>> The spec proposal [1] is ready for review again, I have >>>>>>> also updated the reference implementation too from client side [2] per >>>>>>> spec. >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> Please do have a pass and vote based on how you all >>>>>>> feel, when you get some time. Appreciate all the feedback so far ! >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> [1] https://github.com/apache/iceberg/pull/13810 >>>>>>> >> > >>>>>>> [2] https://github.com/apache/iceberg/pull/13979 >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> Best, >>>>>>> >> > >>>>>>> Prashant Singh >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> >>>>>>> >> > >>>>>>> On Fri, Sep 5, 2025 at 10:04 AM Prashant Singh < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>> >>>>>>> >> > >>>>>>>> Thanks for the feedback, Ryan. I agree that we should >>>>>>> leave the vote open longer and get the wording right. I'll work on >>>>>>> addressing the new feedbacks. >>>>>>> >> > >>>>>>>> >>>>>>> >> > >>>>>>>> Best, >>>>>>> >> > >>>>>>>> Prashant Singh >>>>>>> >> > >>>>>>>> >>>>>>> >> > >>>>>>>> On Fri, Sep 5, 2025 at 8:59 AM Ryan Blue < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>>> >>>>>>> >> > >>>>>>>>> I think this is a good addition, but I think it may >>>>>>> need a bit of work to get the wording right and there's still ongoing >>>>>>> discussion. Maybe we should leave this vote open longer until the >>>>>>> discussion settles? >>>>>>> >> > >>>>>>>>> >>>>>>> >> > >>>>>>>>> Also, I want to point out that this is another use of >>>>>>> a specific separator char. I think it would be good to revisit our >>>>>>> separator discussion and finally close on it. >>>>>>> >> > >>>>>>>>> >>>>>>> >> > >>>>>>>>> On Fri, Sep 5, 2025 at 12:33 AM John Zhuge < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>>>> >>>>>>> >> > >>>>>>>>>> +1 (non-binding) >>>>>>> >> > >>>>>>>>>> >>>>>>> >> > >>>>>>>>>> On Thu, Sep 4, 2025 at 6:23 PM Yufei Gu < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>> +1 on the spec change. It’s a solid first step >>>>>>> toward enabling DEFINER views. As usual, the spec change is >>>>>>> intentionally >>>>>>> kept separate from access control. >>>>>>> >> > >>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>> Yufei >>>>>>> >> > >>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>> On Wed, Sep 3, 2025 at 8:18 AM huaxin gao < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>> +1 (non-binding) >>>>>>> >> > >>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>> On Tue, Sep 2, 2025 at 6:38 PM Prashant Singh < >>>>>>> [email protected]> wrote: >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> Hi All, >>>>>>> >> > >>>>>>>>>>>>> I propose adding an optional referenced-by to the >>>>>>> REST loadTable call, which will contain the fully qualified name of the >>>>>>> view (namespace of the view name and the view name) in case the table is >>>>>>> being referenced by a view. >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> This will be really helpful in a couple of ways : >>>>>>> >> > >>>>>>>>>>>>> 1. First step towards enabling DEFINER views >>>>>>> >> > >>>>>>>>>>>>> 2. Audit, incase one wants to track what's the >>>>>>> base objects accessed from the direct object accessed (example: doc) >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> For details please check: >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> - Spec change PR: >>>>>>> https://github.com/apache/iceberg/pull/13810 >>>>>>> >> > >>>>>>>>>>>>> - Reference Implementation PR: >>>>>>> https://github.com/apache/iceberg/pull/13979 >>>>>>> >> > >>>>>>>>>>>>> - Discuss Thread: >>>>>>> https://lists.apache.org/thread/01gb9rygdd1gqks7lnl1o6440qocnh9m >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> Please vote in the next 72 hours: >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> [ ] +1 Add these changes to the spec >>>>>>> >> > >>>>>>>>>>>>> [ ] +0 >>>>>>> >> > >>>>>>>>>>>>> [ ] -1 I have questions and/or concerns >>>>>>> >> > >>>>>>>>>>>>> >>>>>>> >> > >>>>>>>>>>>>> Best, >>>>>>> >> > >>>>>>>>>>>>> Prashant Singh >>>>>>> >> > >>>>>>>>>> >>>>>>> >> > >>>>>>>>>> >>>>>>> >> > >>>>>>>>>> >>>>>>> >> > >>>>>>>>>> -- >>>>>>> >> > >>>>>>>>>> John Zhuge >>>>>>> >> > >>>>>>> >>>>>>
