[
https://issues.apache.org/jira/browse/IMPALA-10505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Quanlong Huang updated IMPALA-10505:
------------------------------------
Fix Version/s: Impala 4.0.0
> Avoid creating misleading audit logs when a requesting user does not have
> privileges on the underlying tables of a view
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: IMPALA-10505
> URL: https://issues.apache.org/jira/browse/IMPALA-10505
> Project: IMPALA
> Issue Type: Bug
> Reporter: Fang-Yu Rao
> Assignee: Fang-Yu Rao
> Priority: Major
> Fix For: Impala 4.0.0
>
>
> We found that misleading audit logs could be generated in Impala if a
> requesting user granted the privileges on a view does not have the privileges
> on the table(s) on which the view is based. Such an issue could be reproduced
> as follows.
> # Start an authorization-enabled Impala cluster.
> # As the user {{admin}}, execute "{{CREATE VIEW
> default.v_functional_alltypestiny AS SELECT id, bool_col FROM
> functional.alltypestiny;}}".
> # As the user {{admin}}, execute "{{GRANT SELECT ON TABLE
> default.v_functional_alltypestiny TO USER non_owner;}}".
> # As the user {{admin}}, execute "{{REFRESH AUTHORIZATION;}}".
> # Add a break point at
> [RangerBufferAuditHandler#flush()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/ranger/RangerBufferAuditHandler.java#L122]
> to observe the {{AuthzZuditEvent}}'s added to '{{auditEvents_}}' after the
> following statement.
> # As the user {{non_owner}}, execute "{{SELECT COUNT(\*) FROM
> default.v_functional_alltypestiny;}}"
> We will find that only 1 {{AuthzAuditEvent}} was logged. Specifically, the
> field of '{{resourcePath}}' is "{{functional/alltypestiny}}" and the field of
> '{{accessResult}}' is 0, indicating this is a failed authorization for the
> underlying table of the view. But actually the user '{{non_owner}}' is and
> should be allowed to execute the statement since it was granted the privilege
> on the view.
> Therefore, we should remove such a confusing log entry and also retain the
> audit log entry corresponding to the privilege check for the view, i.e.,
> {{default.v_functional_alltypestiny}}.
> I have the following findings after an initial investigation.
> Under the hood Impala performed 2 privileges checks. One for the view and the
> other for the table on which the view is based. Since the user has been
> granted the {{SELECT}} privilege on the view, the first privilege check would
> succeed, whereas the second privilege check would fail since the user does
> not have the {{SELECT}} privilege on the underlying table.
> Each privilege check resulted in one audit log entry generated by the Ranger
> server. Thus the first audit log entry would be a successful audit event
> because it corresponds to the privilege check for the view. However, the
> second privilege check resulted in a failed audit event since it corresponds
> to the privilege check for the underlying table and the requesting user does
> not have the {{SELECT}} privilege on the table. Impala performed the 2nd
> check for a reason. In short, the requesting user is not allowed to access
> the runtime profile if the user does not have the privileges on the
> underlying table(s). Refer to
> [BaseAuthorizationChecker#authorize()|https://github.com/apache/impala/blob/aeeff53e884a67ee7f5980654a1d394c6e3e34ac/fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java#L175-L190]
> for further details.
> On the other hand, for a list of audit events resulting from a query, if
> there exists a failed audit event, only the first failed audit event would be
> kept by Impala and then sent to Ranger. That is the reason why in the end we
> only saw that failed audit event.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
