I think that ownership should be managed by the catalog and should not be set by table properties. Respecting an "owner" property would easily lead to security issues where writers can change the property with write access. I think ownership or what role is the definer, like other security attributes, should be managed by the catalog outside of table properties.
It's also reasonable to include in the proposal that this is necessary but not sufficient to build secure views. A catalog also needs to establish that the engine is trusted and would also need to validate that the principal loading the table has access to the view. But these are catalog problems. While they can be noted in this proposal, it's up to the catalog to design the policy and enforce it. On Tue, Aug 19, 2025 at 7:34 PM Sung Yun <sun...@apache.org> wrote: > Hi Prashant, > > Thanks for sharing this proposal! This has been top of mind for me as > well, since I’m working on integrating Trino with Iceberg while also > supporting other heterogeneous engines in the ecosystem. > > I agree that a change like this is necessary to enable SECURITY DEFINER > views to correctly provision metadata for the underlying tables. That said, > even if it’s out of scope for this document, I think it would be valuable > to also discuss potential attack vectors. Adopters of this feature should > be aware of the additional risk surface it introduces if there isn’t a > trusted security contract between the client and the catalog. > > I’d also support converging on a consistent metadata property convention > for view ownership and security mode, so we have a common foundation across > engines. > > Curious to hear what others think. > > Best, > Sung > > On 2025/08/18 22:20:33 Prashant Singh wrote: > > 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 > > >
