[
https://issues.apache.org/jira/browse/IMPALA-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100066#comment-17100066
]
Fang-Yu Rao commented on IMPALA-9341:
-------------------------------------
After some initial investigation, I found that this issue occurs when the
granted permission (i.e., {{INSERT}}) and the revoked permission (i.e.,
{{SELECT}}) for the resource (i.e., {{functional.alltypes}}) do NOT match.
Taking a closer look at the method
{{RangerCatalogdAuthorizationManager#createGrantRevokeRequest()}} at
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/authorization/ranger/RangerCatalogdAuthorizationManager.java#L281-L306
that generates the corresponding {{GrantRevokeRequest}} to revoke the
privilege of {{SELECT}}, I found that this problem would not emerge as long as
we change the statement of {{request.setDelegateAdmin(isGrant ==
withGrantOpt)}} to {{request.setDelegateAdmin(isGrant && withGrantOpt)}}, where
{{isGrant}} denotes whether this SQL statement is a {{GRANT}} statement and
{{withGrantOpt}} denotes whether this statement is a {{GRANT OPTION}} statement.
The {{REVOKE}} statement above to reproduce the issue corresponds to the case
when {{isGrant}} is {{false}} and {{withGrantOpt}} is {{false}} and thus the
field of {{delegateAdmin}} of {{request}} will be set to {{true}} since
{{(isGrant == withGrantOpt)}} evaluates to {{true}}. Once we change
{{request.setDelegateAdmin(isGrant == withGrantOpt)}} to
{{request.setDelegateAdmin(isGrant && withGrantOpt)}}, {{delegateAdmin}} of
{{request}} will be set to {{false}} and after the change, we do not see this
issue anymore.
So the problem is boiled down to whether it is appropriate/correct to set the
field of {{delegateAdmin}} to {{false}} when generating such a
{{GrantRevokeRequest}}. Note that this issue does NOT occur when the granted
permission and the revoked permission for the resource match. When the granted
permission and the revoked permission for the resource match, the permission
can be correctly revoked regardless of the value of {{delegateAdmin}}. In this
regard, we should consult the Ranger team about this since in the end, this
{{GrantRevokeRequest}} will be used to invoke
{{RangerBasePlugin#revokeAccess()}} at
https://github.com/apache/ranger/blob/8b963d304c77f7daf86131a514f1744a44b485b1/agents-common/src/main/java/org/apache/ranger/plugin/service/RangerBasePlugin.java#L508-L532.
> A grantee gains the delegation privilege after a revoke statement
> -----------------------------------------------------------------
>
> Key: IMPALA-9341
> URL: https://issues.apache.org/jira/browse/IMPALA-9341
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 3.4.0
> Reporter: Fang-Yu Rao
> Assignee: Fang-Yu Rao
> Priority: Major
>
> When Ranger is used as the authorization provider, a grantee that was granted
> the {{insert}} privilege on a table without the delegation privilege gains
> the delegation privilege after executing a statement to {{revoke}} the
> grantee's {{select}} privilege on the same table. In what follows, we provide
> the steps to reproduce the issue.
> # Start a Ranger-enabled Impala minicluster.
> # Log into Impala shell as the user {{admin}} using "{{./bin/impala-shell.sh
> -u admin}}".
> # Execute "{{grant insert on table <table_name> to user
> <user_name_of_grantee>;}}".
> # Execute "{{show grant user <user_name_of_grantee> on table <table_name>;}}".
> # Execute "{{revoke select on table <table_name> from user
> <user_name_of_grantee>;}}".
> # Execute "{{show grant user <user_name_of_grantee> on table <table_name>;}}".
> When {{<table_name>}} equals "{{functional.alltypes}}" and
> {{<user_name_of_grantee>}} equals "{{non_owner}}" which was not granted any
> privilege at the very beginning, after the 4th step, we will see the
> following.
> {code:java}
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> | principal_type | principal_name | database | table | column | uri |
> udf | privilege | grant_option | create_time |
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> | USER | non_owner | functional | alltypes | * | |
> | insert | false | 1580345254347 |
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> {code}
> However, we will see the following after the 6th step above. We can see the
> field of {{grant_option}} is changed from {{false}} to {{true}}, which should
> not happen.
> {code:java}
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> | principal_type | principal_name | database | table | column | uri |
> udf | privilege | grant_option | create_time |
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> | USER | non_owner | functional | alltypes | * | |
> | insert | true | 1580345254347 |
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
