Hi everyone, I wanted to bring up a small but important change to how we handle view security in Iceberg, especially for *DEFINER* views. This change is crucial for ensuring views function as a secure gateway to sensitive data, where access is determined by the view's creator, not the user running the query.
The Problem Currently, when a view queries a table, the loadTable request to the REST catalog doesn't know that it's coming from a view. It just sees the table's name and defaults to checking the permissions of the user running the query. This does not work well with the security model for *DEFINER* views and prevents them from working as intended. The Proposed Solution (PR-13810 <https://github.com/apache/iceberg/pull/13810>) To address this, I've created a pull request that adds an optional loaded-via field to the loadTable request. This field will contain the fully qualified name of the view (e.g., my_db.secure_view) i.e namespace and the view name. When the catalog sees this new field, it will know to perform the security check against the view's owner, not the query invoker. This small addition ensures that the view's security semantics are respected, and it's backward-compatible with existing clients. I've also included a simple proof-of-concept (POC) to show how a client could implement this, along with Spark. I'm open to feedback on the approach, especially on how to cleanly pass the view context to the loadTable request, the POC is just for demonstration *POV*. You can view the full proposal (Iceberg View Security <https://docs.google.com/document/d/15zgmACxue8jH8SIBAJNzZ64Mx6RTRmDv2IoH3Clc2uQ/edit?tab=t.0>) and for details can refer PR-13810 <https://github.com/apache/iceberg/pull/13810> Looking forward to your thoughts. Best, Prashant Singh
