[ 
https://issues.apache.org/jira/browse/IMPALA-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fang-Yu Rao updated IMPALA-9341:
--------------------------------
    Description: 
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 "{{fangyurao}}", 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           | fangyurao      | functional | alltypes | *      |     |     
| insert    | false        | 1580345254347 |
+----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
{code}


However, we will see the following after the 6th step above. We can see the 
filed 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           | fangyurao      | functional | alltypes | *      |     |     
| insert    | true         | 1580345254347 |
+----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
{code}


  was:
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 {{fangyurao}}, 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           | fangyurao      | functional | alltypes | *      |     |     
| insert    | false        | 1580345254347 |
+----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
{code}


However, we will see the following after the 6th step above. We can see the 
filed 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           | fangyurao      | functional | alltypes | *      |     |     
| insert    | true         | 1580345254347 |
+----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
{code}



> A grantee gains the delegation privilege after executing 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 "{{fangyurao}}", 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           | fangyurao      | functional | alltypes | *      |     |    
>  | insert    | false        | 1580345254347 |
> +----------------+----------------+------------+----------+--------+-----+-----+-----------+--------------+---------------+
> {code}
> However, we will see the following after the 6th step above. We can see the 
> filed 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           | fangyurao      | 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]

Reply via email to