I'm not sure that we need more time to review and comment since this is similar to what we've been discussing for a while now. I'd recommend getting started on a detailed proposal with REST spec changes, like what Christian did for the events endpoint.
On Mon, Jul 21, 2025 at 10:06 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi > > DISCLAIMER: I did a review/pass on the proposal before it reached the > dev@ mailing list. > > After working with Prashant, Russell, Laurent on the "secured view" > FGAC proposal, I think this proposal is a good alternative. We can > start with "simple" boolean, up to a more complex dialect support. The > proposal doesn't go into the details, in order to collaborate with the > community about implementation thoughts. > > I propose: > 1. Give more time for people to review/comment on the proposal > 2. Schedule a discussion meeting about the proposal > > If there is no objection after the meeting, we will create the GH > issue and work with the community for the implementation. > > Thoughts ? > > Thanks ! > > Regards > JB > > > On Tue, Jul 22, 2025 at 1:54 AM Prashant Singh <prashant010...@gmail.com> > wrote: > > > > +1, I agree here too, having iceberg expressions for row-filters and > transforms for projections aka column masks seems the right way to go, > especially how portable and dialect agnostic they are ! As said above, we > can always model complex mask / row filters that require JOINs etc as > catalog UDF and reference them in the expression and transform. > > Plus having this representation would be really helpful in merging the > policies as well and perform some basic boolean simplification and constant > folding specially with context resolution so that final projection list aka > transforms along with the filters apply can be conveyed back, > > > > It will be really nice to see this move forward ! > > > > Best, > > Prashant Singh > > > > > > On Mon, Jul 21, 2025 at 3:56 PM Ryan Blue <rdb...@gmail.com> wrote: > >> > >> I agree with Russell. The proposal doesn't look too controversial given > previous discussions on how to support FGAC managed by the catalog. I also > agree that a more detailed proposal should use Iceberg expressions and > transforms for the row-level filters and column mask expressions, and > catalog-managed UDFs can handle more complex representations (like > Substrait mentioned in the proposal) and expressions (like EXISTS with a > sub-query). > >> > >> It would be great to see this move forward. I think it's a good > approach. > >> > >> On Mon, Jul 21, 2025 at 2:17 PM Russell Spitzer < > russellspit...@apache.org> wrote: > >>> > >>> I think this is a really interesting approach as we've talked about in > a few community > >>> syncs as well as in some other chats. If I understand the proposal > correctly, we are > >>> essentially formalizing a way to return the FGAC "protection > expressions" from the catalog > >>> to a trusted engine for execution. > >>> > >>> The only aspects I'm a little more nervous about are allowing dialects > into the api (Sql or Substrait) .. I think the UDFs being worked on can > probably handle that sort of > >>> complexity when it is required and we can stick to Iceberg expressions > and transforms (which could refer to udfs) at least for a first version of > these end points. I believe the are already > >>> efforts and discussions around constraints using this approach as well > as corresponding > >>> work within Spark to make these exchanges more straightforward. > >>> > >>> I think if we minimize the surface area here we can probably figure > out this API relatively quickly. > >>> > >>> On 2025/06/18 14:47:19 Robert Stupp wrote: > >>> > Hi all, > >>> > > >>> > We, the authors of the proposal [1], have been thinking about support > >>> > for fine grained access control for quite some time and would like to > >>> > propose both row-level access control and column-level transformation > >>> > (“masking”) to the Iceberg REST catalog in an interoperable way. > >>> > > >>> > The three main drivers for the proposed approach are > >>> > * interoperability between catalogs and query engines > >>> > * securely applying the FGAC policies > >>> > * ability to integrate any query engines > >>> > > >>> > The proposal describes the general, high-level approach and does > >>> > intentionally not go into specific internal & technical details to > focus > >>> > on the concept as a whole. If there is consensus on the concept > >>> > described in the proposal, we can start a follow-up proposal > considering > >>> > all the feedback - that would include details about the REST > >>> > specification and the technical interaction and between catalogs and > >>> > query engines, as well as portable representation of the policies and > >>> > “protection instructions” (details what the latter is are in the > proposal). > >>> > > >>> > We would love to get your feedback and are happy to answer any > questions! > >>> > > >>> > Robert > >>> > > >>> > [1] Proposal document > >>> > > https://docs.google.com/document/d/1A5EHXZoluvW7GtEth3GzQz6n5N-fErYLtUbf6B93Pmw > >>> > > >>> > > >>> > >
