Hi folks, I've only recently started learning about the Read Restrictions proposal and I'm trying to understand it better from an implementer's perspective. I realize the spec isn't final but given the amount of work already done, I'm hoping others have already thought about these topics. If there are past email threads where these topics have already been discussed please let me know.
1. It appears that the trust relationship is considered outside the scope of this proposal, but a solution for it feels critical to a working implementation. How are other implementers approaching this? In my opinion extending trust for Read Restrictions that we extend today to clients we vend credentials to is not a good model. Today we vend credentials only if you have full access to a table. Anything you can then do with the underlying files is equivalent to what you can do with the table. However, Read Restrictions breaks that model. If you have read restrictions you may only have access to a subset of an individual file. We need a way to trust that when we give a credential that implicitly gives access to a full file (or set of files) to an engine that will properly protect the credential and faithfully and correctly restrict the file contents returned to a consumer. My concern is that without a solution to this (even one defined outside this spec) we will have a spec that only ever exists on paper and cannot be used in practice. 2. A number of catalogs already have different fine grained access control capabilities in their native formats and I expect these will also get made available via Iceberg Rest Catalog interfaces. Many of the column mask and row filter capabilities may or may not translate directly to the pre-defined Read Restriction functions. How are other implementers approaching the translation problem? If there is no clear translation, the safe approach will certainly be to fail the request. Recognizing that an arbitrary SQL UDF is functionally equivalent to the defined spec of a Read Restriction function may be tricky to get right. 3. Does the spec offer any opinion on how clients should execute Read Restriction functions? Postgres has a great writeup in their documentation on the danger of not including a security barrier in views and how information can be leaked: https://www.postgresql.org/docs/current/rules-privileges.html. I would consider this closely related to my first question. As an implementer, I may want to trust a client that correctly implements a security barrier and not trust clients that don't. 4. Does the spec apply only to tables or all table-like objects including views? Thanks, Corey Sunwold
