[jira] [Comment Edited] (IMPALA-12190) Renaming table will cause losing privileges for non-admin users

["Fang-Yu Rao (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-12190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848439#comment-17848439 ] 

Fang-Yu Rao edited comment on IMPALA-12190 at 5/22/24 4:15 AM:
---------------------------------------------------------------

This JIRA does not seem to be straightforward to resolve on the Impala side alone because the error handling could be tricky. I think we may need Apache Ranger to provide an API that could take care of this for us (Apache Impala). Specifically, it would be great if there is a Ranger API that is able to modify the policies accordingly when the catalog server alters the name of a table. For instance, when the catalog server is executing ALTER TABLE RENAME, the catalog server also sends to the Ranger server via Impala's Ranger plug-in a request to change the name of the table in Ranger's policy repository if there is a policy matching this table. Ranger stores its policies in its backend database, so it would be much easier for Ranger to manage this operation, especially when there is an error/exception  that occurs during the execution of the operation.

 

If we'd like to resolve this from Apache Impala alone, then we have to be able to do the following properly.
 # Retrieve the policy matching the name of the table whose name is going to be altered.
 # For each grantee principal in the policy (which could be a user, group, or a role) in the policy retrieved above, issue a REVOKE statement to revoke this grantee's privileges on the old table (the table before the renaming) and then issue a GRANT statement to grant those previously revoked privileges to this grantee on the new table (the table with the new name). A grantee could have multiple privileges on the table so multiple REVOKE/GRANT could be required.

It seems a bit tricky to handle the errors that occur during the 2nd step described above. For instance, assume that a grantee only has only one privilege granted on the old table, what should the catalog server do when the GRANT command fails after its corresponding REVOKE command? Should we roll back the REVOKE command? Or should we retry the GRANT command?

The policy for a table could also involve multiple principals. What should we do when the operation corresponding to a grantee principal fails?

 

On the other hand, there does not seem to be a Ranger API that allows us to retrieve the exact policy matching a given table name.
There is a Ranger API that could return an access control list (ACL) given the name of a resource, e.g., the table "functional.alltypes". A place where we call this is within RangerImpaladAuthorizationManager#getPrivileges() ([plugin_.get().getResourceACLs(request)|https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/authorization/ranger/RangerImpaladAuthorizationManager.java#L367]), which could be triggered by a statement like "SHOW GRANT USER non_owner ON TABLE functional.alltypes".

For instance, given the table name "functional.alltypes", we could get a HashMap called "userACLs", and the contents of this map could look like the following. Note that in the following, only the first map corresponds to the policy in which the resource is exactly the table "functional.alltypes". This policy was created by an administrative user via "GRANT SELECT ON TABLE functional.alltypes to USER non_owner". The rest of the maps were inferred by other policies. Take the 2nd map, the user "hdfs" has the privileges on the table "functional.alltypes" through the policy that grants "hdfs" the ALL privilege on all the databases, tables, and columns.
 # "non_owner" -> {"select" -> "ALLOWED"}
 # "hdfs" -> \{"all" -> "ALLOWED", "drop" -> "ALLOWED", ...}
 # "admin" -> \{"drop" -> "ALLOWED", "all" -> "ALLOWED", ...}
 # "\{OWNER}" -> \{"all" -> "ALLOWED", "drop" -> "ALLOWED", ...}


was (Author: fangyurao):
This JIRA does not seem to be straightforward to resolve on the Impala side alone because the error handling could be tricky. I think we may need Apache Ranger to provide an API that could take care of this for us (Apache Impala). Specifically, it would be great if there is a Ranger API that is able to modify the policies accordingly when the catalog server alters the name of a table. For instance, when the catalog server is executing ALTER TABLE RENAME, the catalog server also sends to the Ranger server via Impala's Ranger plug-in a request to change the name of the table in Ranger's policy repository if there is a policy matching this table. Ranger stores its policies in its backend database, so it would be much easier for Ranger to manage this operation, especially when there is an error/exception  that occurs during the execution of the operation.

 

If we'd like to resolve this from Apache Impala alone, then we have to be able to do the following properly.
 # Retrieve the policy matching the name of the table whose name is going to be altered.
 # For each grantee principal in the policy (which could be a user, group, or a role) in the policy retrieved above, issue a REVOKE statement to revoke this grantee's privileges on the old table (the table before the renaming) and then issue a GRANT statement to grant those previously revoked privileges to this grantee on the new table (the table with the new name). A grantee could have multiple privileges on the table so multiple REVOKE/GRANT could be required.

It seems a bit tricky to handle the errors that occur during the 2nd step described above. For instance, assume that a grantee only has only one privilege granted on the old table, what should the catalog server do when the GRANT command fails after its corresponding REVOKE command? Should we roll back the REVOKE command? Or should we retry the GRANT command?

The policy for a table could also involve multiple principals. What should we do when the operation corresponding to a grantee principal fails?

 

On the other hand, there does not seem to be a Ranger API that allows us to retrieve the exact policy matching a given table name.
There is a Ranger API that could return an access control list (ACL) given the name of a resource, e.g., the table "functional.alltypes". A place where we call this is within RangerImpaladAuthorizationManager#getPrivileges() ([plugin_.get().getResourceACLs(request)|https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/authorization/ranger/RangerImpaladAuthorizationManager.java#L367]), which could be triggered by a statement like "SHOW GRANT USER non_owner ON TABLE functional.alltypes".

For instance, given the table name "functional.alltypes", we could get a HashMap called "userACLs", and the contents of this map could look like the following. Note that in the following, only the first map corresponds to the policy in which the resource is exactly the table "functional.alltypes". This policy was created by an administrative user via "GRANT SELECT ON TABLE functional.alltypes to USER non_owner". The rest of the maps were inferred by other policies. Take the 2nd map, the user "hdfs" has the privileges on the table "functional.alltypes" through the policy that grants "hdfs" the ALL privilege on all the databases, tables, and columns.
 # "non_owner" -> \{"select"-> "ALLOWED"}
 # "hdfs" -> \{"all" -> "ALLOWED", "drop" -> "ALLOWED", ...}
 # "admin" -> \{"drop" -> "ALLOWED", "all" -> "ALLOWED", ...}
 # "\{OWNER}" -> \{"all" -> "ALLOWED", "drop" -> "ALLOWED", ...}

> Renaming table will cause losing privileges for non-admin users
> ---------------------------------------------------------------
>
>                 Key: IMPALA-12190
>                 URL: https://issues.apache.org/jira/browse/IMPALA-12190
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Catalog
>            Reporter: Gabor Kaszab
>            Assignee: Sai Hemanth Gantasala
>            Priority: Critical
>              Labels: alter-table, authorization, ranger
>
> Let's say user 'a' gets some privileges on table 't'. When this table gets renamed (even by user 'a') then user 'a' loses its privileges on that table.
>  
> Repro steps:
>  # Start impala with Ranger
>  # start impala-shell as admin (-u admin)
>  # create table tmp (i int, s string) stored as parquet;
>  # grant all on table tmp to user <username>;
>  # grant all on table tmp to user <username>;
> {code:java}
> Query: show grant user <username> on table tmp
> +----------------+----------------+----------+-------+--------+-----+--------------+-------------+-----+-----------+--------------+-------------+
> | principal_type | principal_name | database | table | column | uri | storage_type | storage_uri | udf | privilege | grant_option | create_time |
> +----------------+----------------+----------+-------+--------+-----+--------------+-------------+-----+-----------+--------------+-------------+
> | USER           | <username>    | default  | tmp   | *      |     |              |             |     | all       | false        | NULL        |
> +----------------+----------------+----------+-------+--------+-----+--------------+-------------+-----+-----------+--------------+-------------+
> Fetched 1 row(s) in 0.01s {code}
>  #  alter table tmp rename to tmp_1234;
>  # show grant user <username> on table tmp_1234;
> {code:java}
> Query: show grant user <username> on table tmp_1234
> Fetched 0 row(s) in 0.17s{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org