[jira] [Commented] (IMPALA-10728) Impala should check access privileges inside masking expressions

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-10728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17359210#comment-17359210 ] 

ASF subversion and git services commented on IMPALA-10728:
----------------------------------------------------------

Commit 0c89a9cf0f2b642ca214e4fa68eeea9bc32ef3af in impala's branch refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=0c89a9c ]

IMPALA-10728: Check access privileges inside masking expressions

Row-filtering/column-masking policies may introduce new expressions or
tables to the original query, e.g. a column-masking policy can reference
other columns that are not used by the original query, a row-filtering
policy can filter rows based on a subquery on other tables.

Previously, we intend to not checking accesses on these expressions and
tables. One reason is that they are hidden and users are not aware of
them. The other reason is the expressions are considered to be evaluated
by the admin (who creates these policies and has access to all
resources). The same for masking policies, i.e. if the hidden tables
have masking policies, those policies are not applied recursively. This
also avoids infinitely recursively masking.

Hive has the same behavior on masking policies. However, Hive does check
access privileges inside the masking expressions. To avoid breaking
users who may have already depended on this, we adjust our behavior to
check access privileges inside the masking expressions as well. Due to
this, audits will also be generated on accessing the additional columns.

Implementation:
Before this patch, we only collect privilege requests when analyzing the
original query. When masking expressions are applied and query rewrite
rules are applied, we re-analyze the AST without collecting privilege
requests. This patch adjusts the behavior to also collect them in the
re-analyzing pass after masking expressions are applied.

Tests
 - Add FE tests.
 - Adjust existing FE audit test to verify the additional audits.
 - Run CORE tests.

Change-Id: I772fa2f5d189b1272e8419ed1fb5b34d373d3601
Reviewed-on: http://gerrit.cloudera.org:8080/17550
Reviewed-by: Aman Sinha <am...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> Impala should check access privileges inside masking expressions
> ----------------------------------------------------------------
>
>                 Key: IMPALA-10728
>                 URL: https://issues.apache.org/jira/browse/IMPALA-10728
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend, Security
>    Affects Versions: Impala 4.0
>            Reporter: Quanlong Huang
>            Assignee: Quanlong Huang
>            Priority: Critical
>
> Row-filtering/column-masking policies may have subqueries which involve some other tables. These tables can have associate policies as well. Currently, Impala won't check any policies on these tables, including access policies and masking policies (row-filtering/column-masking). The rational is these expressions are evaluated in admin's point of view. Another reason is to avoid recursive masking, and sometimes infinite recursive masking. E.g. a row-filter subquery can have tables that also have such kind of row-filters.
> Although Hive also skipps applying masking policies recursively inside masking/filtering expressions, Hive still check access policies inside them. To avoid breaking users that depend on this, we'd better be compatible with Hive's behavior first.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org