commit d038e392de8ba453155040f3ca1ae33f03e39b2e
author Fang-Yu Rao <fangyu.rao@cloudera.com> Fri Feb 12 17:31:47 2021 -0800
committer Impala Public Jenkins <impala-public-jenkins@cloudera.com> Thu Feb 25 16:05:11 2021 +0000
tree 249eca16a5ced55585a3021c1c98b32615dd5a01
parent bead2ede1c79fb477d2fb4d2f73703df1e34e97a

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 <impala-public-jenkins@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>