[jira] [Created] (IMPALA-10505) Avoid creating misleading audit logs when a requesting user does not have privileges on the underlying tables of a view

["Fang-Yu Rao (Jira)" <ji...@apache.org>]

Fang-Yu Rao created IMPALA-10505:
------------------------------------

             Summary: 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


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 AuthzZuditEvent 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.3.4#803005)