I don't think that Polaris should change any view definition in any way,
but this is what the proposed approach does.
The approach breaks the contract (behavior defined by the specification)
and in turn the observed behavior, absolute no go's.
Practically speaking, the approach is blindly changing some string
without any knowledge about the actual meaning. But it has to know
exactly what it's doing - and to do that it has to know all the SQL
dialects.
As a side note: every query engine already has information about the
user. I'm definitely not supporting exposing any authZ related information.
FGAC as a feature is a great thing to have. But the proposed approach is
not the right way.
On 19.05.25 20:33, Prashant Singh wrote:
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
--
Robert Stupp
@snazy
