Thanks all, I've started a new thread about the detailed proposal for the endpoint here: https://lists.apache.org/thread/2jx33fn7lq37oxxm7sd6rjy0dnvbm4t6
Robert On Tue, Jul 22, 2025 at 6:49 PM Ryan Blue <[email protected]> wrote: > > 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é <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 >> >> <[email protected]> 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 >> >>> > >> >>> > >> >>> >
