Hey Robert,
Thank you for your honest feedbacks, please let me try answering your
concerns :
> There are tons of SQL dialects out there, each requires its own fully
implemented lexer/parser/interpreter
That's true and we are not interpreting it either, we are just replacing
the sql text wherever there is `is_principal('<principal_name>')` with the
value of TRUE and FALSE from the server end
we are not re-interpreting or parsing the tree, i am assuming this is what
Analyzer already does in constant folding and boolean simplification, but
yes post parsing, but IMHO i don't think it's an impossible thing to
achieve. If it helps i am even fine is wrapping this as
`{{is_principal('<principal_name>')}}` to make this very specific and let
only Polaris work, IMHO we can work out the rough edges with the
replacement.
> for view containing view
This should not be a problem, as we just replace the text of the current
view definition when it comes to resolve the nested view it will issue the
same call of LOAD view but with the nested view identifier, when it will be
the call of nested view and that's when i we will do the replace
we don't open the nested view in the definition during the loadView of the
parent, if that's the concern here, the nested view is treated equivalent
to any other identifier which is opened / interpreted at later state of
execution.
> Exposing authZ information via any kind of publicly accessible API to
every user sounds like an interesting source of information - especially
for the "not so good and nice guys".
Yes that's true and that's my intention it's just how we are delivering the
info, i.e i expose it by view definition itself (or by any other entity
stored in Polaris) , but exposing this as an API would require engine side
integration too, which we as catalog have a very less control over as a
catalog.
> What's the benefit over having the ACLs on the table/view defined in the
intended way?
It's more from feature parity perspective and giving more control on view
rather than just ACL (which are conjunctions) for ex if we just complicate
the view def with more predicated for ex disjunction
select * from ns1.layer1_table where (condition1) OR
(is_principal_role('ANALYST'))
I would love to get your further feedback, considering the above.
Best,
Prashant Singh
On Mon, May 19, 2025 at 11:04 AM Robert Stupp <sn...@snazy.de> wrote:
> I'm brutally honest here:
>
> I think we should really stay away from interpreting SQL or any other
> kind of (view) definition in Polaris. There are tons of SQL dialects out
> there, each requires its own fully implemented lexer/parser/interpreter
> - plus views-in-views-in-views-in-views... constructs requiring
> resolution of nested views. It eventually ends in implementing
> yet-another-query-engine. I doubt that this is doable with a
> "java.lang.String.replace(from, to)" approach.
>
> Exposing authZ information via any kind of publicly accessible API to
> every user sounds like an interesting source of information - especially
> for the "not so good and nice guys".
>
> Regarding the examples: what's the benefit over having the the ACLs on
> the table/view defined in the intended way?
>
> On 19.05.25 19:26, Prashant Singh 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
> >
> --
> Robert Stupp
> @snazy
>
>
