[
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 6:35 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 (which could be a user, group, or a role) in the
policy retrieved above, invoke the REVOKE API to revoke this grantee's
privileges on the old table (the table before the renaming) and then invoke the
GRANT API 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 API call fails after its corresponding REVOKE API call? Should we roll
back the REVOKE API call? Or should we retry the GRANT API call?
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, invoke the REVOKE API to revoke this
grantee's privileges on the old table (the table before the renaming) and then
invoke the GRANT API 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 API call fails after its corresponding REVOKE API call? Should we roll
back the REVOKE API call? Or should we retry the GRANT API call?
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: [email protected]
For additional commands, e-mail: [email protected]
