Fang-Yu Rao has uploaded this change for review. ( http://gerrit.cloudera.org:8080/16013
Change subject: IMPALA-9341: Check current delegateAdmin value when performing REVOKE ...................................................................... IMPALA-9341: Check current delegateAdmin value when performing REVOKE When executing a GRANT or REVOKE statement with Ranger being the authorization provider, Impala has to prepare a GrantRevokeRequest to allow Ranger to add/delete the corresponding RangerPolicy or modify the existing RangerPolicyItem's in the related RangerPolicy. One of the fields that has to be set in a GrantRevokeRequest is delegateAdmin, which dictates whether the grantee is allowed to transfer the privilege on the resource to other principals. Specifically, the field of delegateAdmin in the updated RangerPolicyItem corresponding to the grantee would be set to the value of delegateAdmin in the GrantRevokeRequest prepared by Impala. Before this patch, when executing a REVOKE statement without the GRANT OPTION, Impala would set delegateAdmin in the GrantRevokeRequest to true. This is fine if the privilege to be revoked is the only privilege that was previously granted to the grantee. However, in the case when the privilege to be revoked was not granted and there is a RangerPolicyItem with respect to the other privilege on the same resource, the grantee actually obtains the permission to transfer the non-matching privilege afterwards. The root cause of this issue is that the privileges on the same resource share the same field of delegateAdmin in the corresponding RangerPolicyItem, a current limitation of Ranger. One might be wondering the aforementioned issue could be simply resolved by always setting the delegateAdmin field in a GrantRevokeRequest to false for a REVOKE statement without the GRANT OPTION. However, in the case when the grantee was permitted to transfer the non-matching privilege, setting delegateAdmin to false in the GrantRevokeRequest would deprive the grantee of the permission that should not have been revoked, making it a bit inconvenient for both the administrator and the grantee since the permission to transfer the non-matching privilege should be restored afterwards. This patch attempts to resolve this problem by 1) checking whether or not there exists a RangerPolicyItem with respect to the same resource and the grantee such that the delegateAdmin field is set to true and 2) setting up the delegateAdmin field in the GrantRevokeRequest accordingly. Testing: - Added a test case in test_ranger.py to verify the issue is fixed. - Verified this patch passes the exhaustive tests in the DEBUG build except for 3 unrelated E2E tests. Change-Id: Ib02c51bd15c94c1fb6b1776ecfd7ec3eeafc4e2c --- M fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java M fe/src/test/java/org/apache/impala/authorization/AuthorizationTestBase.java M tests/authorization/test_ranger.py 3 files changed, 134 insertions(+), 26 deletions(-) git pull ssh://gerrit.cloudera.org:29418/Impala-ASF refs/changes/13/16013/1 -- To view, visit http://gerrit.cloudera.org:8080/16013 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-MessageType: newchange Gerrit-Change-Id: Ib02c51bd15c94c1fb6b1776ecfd7ec3eeafc4e2c Gerrit-Change-Number: 16013 Gerrit-PatchSet: 1 Gerrit-Owner: Fang-Yu Rao <[email protected]>
