You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by ta...@apache.org on 2020/06/18 21:41:52 UTC
[impala] 01/03: IMPALA-9341: Set delegateAdmin to false for REVOKE
without GRANT OPTION
This is an automated email from the ASF dual-hosted git repository.
tarmstrong pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/impala.git
commit 3ba6fcb47909af7c4f22493a94cd08e9b9689a88
Author: Fang-Yu Rao <fa...@cloudera.com>
AuthorDate: Sat Jun 6 15:08:28 2020 -0700
IMPALA-9341: Set delegateAdmin to false for REVOKE without GRANT OPTION
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. In this regard, as a workaround, we set
delegateAdmin in the GrantRevokeRequest to false for a REVOKE statement
without the GRANT OPTION. As a result, delegateAdmin would be false in
the GrantRevokeRequest whether or not the query has the GRANT OPTION.
We would like to point out that there is a limitation of this
workaround. More precisely, 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 if necessary.
An alternative approach is for Impala to always check the current
delegateAdmin value when performing a REVOKE statement without the GRANT
OPTION. Specifically, we could 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. This alternative, however, suffers from the drawback that
additional logic has to be added to iterate over the RangerPolicy's
for the resource in the query, slowing down the query execution.
Therefore, we decide to choose the approach proposed in this patch over
the alternative that is less efficient, which could be found at
https://gerrit.cloudera.org/c/16013/.
Testing:
- Revised a test case in test_ranger.py to reflect the behavior change
of Impala when a REVOKE statement without the GRANT OPTION is
executed.
- Verified that this patch passed the exhaustive tests in the DEBUG
build.
Change-Id: I19ff45a5a30293e9c6cf35b22ea4aa5cb10355c9
Reviewed-on: http://gerrit.cloudera.org:8080/16046
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>
---
.../authorization/ranger/RangerCatalogdAuthorizationManager.java | 2 +-
tests/authorization/test_ranger.py | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java b/fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java
index 9229272..6f741ba 100644
--- a/fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java
+++ b/fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java
@@ -285,7 +285,7 @@ public class RangerCatalogdAuthorizationManager implements AuthorizationManager
request.setGrantor(grantor);
if (user != null) request.getUsers().add(user);
if (!groups.isEmpty()) request.getGroups().addAll(groups);
- request.setDelegateAdmin(isGrant == withGrantOpt);
+ request.setDelegateAdmin(isGrant && withGrantOpt);
request.setEnableAudit(Boolean.TRUE);
request.setReplaceExistingPermissions(Boolean.FALSE);
request.setClusterName(clusterName);
diff --git a/tests/authorization/test_ranger.py b/tests/authorization/test_ranger.py
index ac4d821..42c04d3 100644
--- a/tests/authorization/test_ranger.py
+++ b/tests/authorization/test_ranger.py
@@ -156,9 +156,13 @@ class TestRanger(CustomClusterTestSuite):
.format(unique_database, user1), user=ADMIN)
result = self.execute_query("show grant user {0} on database {1}"
.format(user1, unique_database))
+ # Revoking the select privilege also deprives the grantee of the permission to
+ # transfer other privilege(s) on the same resource to other principals. This is a
+ # current limitation of Ranger since privileges on the same resource share the same
+ # delegateAdmin field in the corresponding RangerPolicyItem.
TestRanger._check_privileges(result, [
- ["USER", user1, unique_database, "", "", "", "*", "insert", "true"],
- ["USER", user1, unique_database, "*", "*", "", "", "insert", "true"]])
+ ["USER", user1, unique_database, "", "", "", "*", "insert", "false"],
+ ["USER", user1, unique_database, "*", "*", "", "", "insert", "false"]])
# Revoke privilege granting from user 1
self.execute_query_expect_success(admin_client, "revoke grant option for insert "