Yes that's true, Engines will be the one executing the view, the idea is
not to break that part but the intention is that we don't want engines to
resolve the identity
it is something the catalog should do. For ex engine might be running with
its own user / groups etc which would not mean anything in Polaris all it
matter when the view was asked
what was the caller's identity and hence get the appropriate view
definition.
A trusted engine should just focus on executing the view and not care about
identity resolution.
Best,
Prashant Singh
On Mon, May 19, 2025 at 10:40 AM Laurent Goujon <laur...@dremio.com.invalid>
wrote:
> Maybe I'm missing something, but aren't the engines the ones actually
> interpreting/executing the views, not Polaris?
>
> On Mon, May 19, 2025 at 10:27 AM Prashant Singh
> <prashant.si...@snowflake.com.invalid> wrote:
>
> > Hi everyone,
> >
> > I’d like to propose adding *context-aware functions* to Apache Polaris so
> > that view definitions can resolve security context on the Polaris side
> (aka
> > catalog end without depending on engines).
> >
> > *Proposed functions*
> >
> > 1.
> >
> > *is_principal('<principal_name>')* – returns TRUE if the authenticated
> > principal matches <principal_name>, otherwise FALSE.
> > 2.
> >
> > *is_principal_role('<principal_role_name>')* – returns TRUE when
> > <principal_role_name> appears in the principal’s role set.
> > 3.
> >
> > *is_catalog_role('<catalog_role_name>')* – analogous check at the
> > catalog-role level.
> >
> > *Why it matters*
> >
> > These predicates make views dynamic. Example:
> >
> > CREATE VIEW dynamic_vw ASSELECT *FROM ns1.layer1_tableWHERE
> > is_principal_role('ANALYST');
> >
> > When a user whose one of principal roles include *ANALYST* calls LOAD
> > VIEW, Polaris rewrites the view to
> >
> >
> > -
> >
> > SELECT * FROM ns1.layer1_table WHERE TRUE;
> >
> >
> > For everyone else the view becomes
> >
> > -
> >
> > SELECT * FROM ns1.layer1_table WHERE FALSE;
> >
> >
> > The result is better and consistent control of the identity resolution
> > without relying on the engine side changes and giving polaris more
> > authority in enforcing things like FGAC (WIP by me).
> > Note the same can be extrapolated to any Polaris stored entity.
> >
> > *Proof of concept*
> >
> > I’ve put together a quick POC branch:
> >
> >
> https://github.com/apache/polaris/compare/main...singhpk234:polaris:dyanmic/view
> >
> > *Prior art*
> >
> > Snowflake context functions :
> > https://docs.snowflake.com/en/sql-reference/functions-context
> > <https://docs.snowflake.com/en/sql-reference/functions-context>
> > Databricks Unity Catalog offers a similar mechanism called *dynamic
> views*:
> > https://docs.databricks.com/aws/en/views/dynamic
> >
> > *Next steps*
> >
> > If the community is interested, we can discuss API surface, engine
> > implications, and a roadmap for merging.
> >
> > Eager to hear your feedback!
> >
> > Best,
> > Prashant Singh
> >
>
