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

Fang-Yu Rao edited comment on IMPALA-7282 at 2/20/20 5:50 AM:
--------------------------------------------------------------

Hi [~joemcdonnell] and [~vihangk1], it seems there are two issues reported 
here. One is the issue originally reported by [~fredyw] and the other is the 
issue reported by [~aholley]. The former issue  does not involve the {{REVOKE}} 
statement, whereas the latter involves the {{REVOKE}} statement.

In the first issue, the behavior of Hive is the same as Impala described at the 
very beginning. That is, if a user previously being granted the {{SELECT}} 
privilege on a database is granted the {{ALL}} privilege on the same database, 
then {{SHOW GRANT ROLE}} statement will only show this user's {{ALL}} privilege 
on the database.

For the second issue, the behavior of Hive is different from that of Impala. 
Specifically, unlike an Impala user who will not possess any privilege on the 
specified column {{col}} after the following 3 SQL statements, a Hive user 
would still possess the {{SELECT}} privilege on the table {{tbl}} afterwards.
{code:java}
GRANT SELECT(col) ON TABLE tbl TO ROLE foo_role;
GRANT SELECT ON SERVER TO ROLE foo_role;
REVOKE SELECT ON SERVER FROM ROLE foo_role; 
{code}
In my view, the behavior of Impala should be acceptable even though its 
behavior is different from Hive in this case. When we revoke from a user the 
{{SELECT}} privilege on {{SERVER}}, which is a superset of the TABLE {{tbl}}, 
it should be fine that in the end this user does not possess the {{SELECT}} 
privilege on any resource under this {{SERVER}}.





was (Author: fangyurao):
Hi [~joemcdonnell] and [~vihangk1], it seems there are two issues reported 
here. One is the issue originally reported by [~fredyw] and the other is the 
issue reported by [~aholley]. The former issue  does not involve the {{REVOKE}} 
statement, whereas the latter involves the {{REVOKE}} statement.

In the first issue, the behavior of Hive is the same as Impala described at the 
very beginning. That is, if a user previously being granted the {{SELECT}} 
privilege on a database is granted the {{ALL}} privilege on the same database, 
then {{SHOW GRANT ROLE}} statement will only show this user's {{ALL}} privilege 
on the database.

For the second issue, the behavior of Hive is different from that of Impala. 
Specifically, unlike an Impala user who will not possess any privilege on the 
specified column {{col}} after the following 3 SQL statements, a Hive user 
would still possess the {{SELECT}} privilege on the table {{tbl}} afterwards.
{code:java}
GRANT SELECT(col) ON TABLE tbl TO ROLE foo_role;
GRANT SELECT ON SERVER TO ROLE foo_role;
REVOKE SELECT ON SERVER FROM ROLE foo_role; 
{code}
In my view, the behavior of Impala should be acceptable. When we revoke from a 
user the {{SELECT}} privilege on {{SERVER}}, which is a superset of the TABLE 
{{tbl}}, it should be fine that in the end this user does not possess the 
{{SELECT}} privilege on any resource under this {{SERVER}}.




> Sentry privilege disappears after a catalog refresh
> ---------------------------------------------------
>
>                 Key: IMPALA-7282
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7282
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Catalog, Security
>    Affects Versions: Impala 3.0, Impala 2.12.0
>            Reporter: Fredy Wijaya
>            Priority: Critical
>              Labels: security
>
> {noformat}
> [localhost:21000] default> grant select on database functional to role 
> foo_role;
> Query: grant select on database functional to role foo_role
> +---------------------------------+
> | summary                         |
> +---------------------------------+
> | Privilege(s) have been granted. |
> +---------------------------------+
> Fetched 1 row(s) in 0.05s
> [localhost:21000] default> grant all on database functional to role foo_role;
> Query: grant all on database functional to role foo_role
> +---------------------------------+
> | summary                         |
> +---------------------------------+
> | Privilege(s) have been granted. |
> +---------------------------------+
> Fetched 1 row(s) in 0.03s
> [localhost:21000] default> show grant role foo_role;
> Query: show grant role foo_role
> +----------+------------+-------+--------+-----+-----------+--------------+-------------+
> | scope    | database   | table | column | uri | privilege | grant_option | 
> create_time |
> +----------+------------+-------+--------+-----+-----------+--------------+-------------+
> | database | functional |       |        |     | select    | false        | 
> NULL        |
> | database | functional |       |        |     | all       | false        | 
> NULL        |
> +----------+------------+-------+--------+-----+-----------+--------------+-------------+
> Fetched 2 row(s) in 0.02s
> [localhost:21000] default> show grant role foo_role;
> Query: show grant role foo_role
> +----------+------------+-------+--------+-----+-----------+--------------+-------------------------------+
> | scope    | database   | table | column | uri | privilege | grant_option | 
> create_time                   |
> +----------+------------+-------+--------+-----+-----------+--------------+-------------------------------+
> | database | functional |       |        |     | all       | false        | 
> Wed, Jul 11 2018 15:38:41.113 |
> +----------+------------+-------+--------+-----+-----------+--------------+-------------------------------+
> Fetched 1 row(s) in 0.01s
> {noformat}



--
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