Fang-Yu Rao has uploaded a new patch set (#5). ( http://gerrit.cloudera.org:8080/17078 )
Change subject: IMPALA-10505: Avoid creating misleading audit logs ...................................................................... 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 --- M fe/src/main/java/org/apache/impala/authorization/BaseAuthorizationChecker.java M fe/src/main/java/org/apache/impala/authorization/NoopAuthorizationFactory.java M fe/src/main/java/org/apache/impala/authorization/ranger/RangerAuthorizationChecker.java M fe/src/test/java/org/apache/impala/authorization/ranger/RangerAuditLogTest.java M fe/src/test/java/org/apache/impala/common/FrontendTestBase.java M tests/authorization/test_ranger.py 6 files changed, 150 insertions(+), 33 deletions(-) git pull ssh://gerrit.cloudera.org:29418/Impala-ASF refs/changes/78/17078/5 -- To view, visit http://gerrit.cloudera.org:8080/17078 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: newpatchset Gerrit-Change-Id: I02f40eb96d6ed863cd2cd88d717c354dc351a64c Gerrit-Change-Number: 17078 Gerrit-PatchSet: 5 Gerrit-Owner: Fang-Yu Rao <fangyu....@cloudera.com> Gerrit-Reviewer: Csaba Ringhofer <csringho...@cloudera.com> Gerrit-Reviewer: Fang-Yu Rao <fangyu....@cloudera.com> Gerrit-Reviewer: Impala Public Jenkins <impala-public-jenk...@cloudera.com> Gerrit-Reviewer: Quanlong Huang <huangquanl...@gmail.com>
