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

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

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

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

Commit d038e392de8ba453155040f3ca1ae33f03e39b2e in impala's branch refs/heads/master from Fang-Yu Rao
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=d038e39 ]

IMPALA-10505: Avoid creating misleading audit logs

Before this patch, if a requesting user granted the privilege on a view
does not have the privilege on the table(s) on which the view is based,
only an audit log entry indicating a failed authorization with respect
to an underlying table will be produced, whereas the requesting user is
actually able to fetch the data from the view since the user is granted
the privilege to do so. Such an audit log entry, however, is misleading
and thus should not be produced at all. Moreover, the audit log entry
corresponding to the successful authorization with respect to the view
should also be created.

Recall that to authorize a query involving a view, Impala performs
privilege checks for both the view as well as the underlying table(s).
Thus, for a user granted the privilege on the view but not the
underlying tables, the privilege check for the view would succeed but
those for the underlying table(s) would fail. Each privilege check
results in an audit log entry produced by Ranger. These audit log
entries will be collected by Impala and will be sent back to Ranger
after the query authorization. In the case where there is at least one
AuthzAuditEvent indicating a failed privilege check, only the
AuthzAuditEvent corresponding to the first failed check will be sent
back to Ranger. Refer to RangerBufferAuditHandler#flush() for further
details. Impala performs checks for both the view as well as the
underlying table(s) so that it is able to disallow the requesting user
from accessing the runtime profile or execution summary when the
requesting user is not granted the privilege on the underlying table(s).
Note that allowing the requesting user the access to the runtime profile
would reveal the existence of the underlying tables.

This patch resolves the issue by specifying whether or not we should
retain the audit log entries when calling
BaseAuthorizationChecker#authorizePrivilegeRequest() so that Impala will
not collect the audit log entries resulting from the privilege checks
for the underlying table(s) of a view.

Testing:
 - Added new FE tests to verify that the correct audit log entry is
   produced after this patch.
 - Added a new E2E test to verify that a user not granted the privilege
   on the underlying table(s) of a view is still not able to access the
   runtime profile or execution summary even though the user is granted
   the privilege on the view.
 - Verified that the patch passes the core tests in the DEBUG build.

Change-Id: I02f40eb96d6ed863cd2cd88d717c354dc351a64c
Reviewed-on: http://gerrit.cloudera.org:8080/17078
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


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

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