You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@sentry.apache.org by "Tony Hill (Jira)" <ji...@apache.org> on 2020/02/18 09:53:00 UTC
[jira] [Updated] (SENTRY-2551) Revoking select at server level
corrupts URI grants
[ https://issues.apache.org/jira/browse/SENTRY-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tony Hill updated SENTRY-2551:
------------------------------
Description:
Revoking "SELECT" permission at the server level changes URI grants from ALL to INSERT, breaking them.
Create a role and assign some permissions:
create role testrole2;
grant all on URI '/user/test2' to role testrole2;
grant all on table customers to role testrole2;
show grant role testrole2;
SHOW GRANT ROLE show expected permissions.
scope database table column uri privilege grant_option create_time
1 uri hdfs://xxxxxx:8020/user/test2 all false Fri, Jan 17 2020 08:13:14.746
2 table default customers all false NULL
Revoke select at the server level
revoke select on server server1 from role testrole2;
In the database, we see the ACTION of the URI has been changed to insert, which is invalid. You can't (manually) create a URI like this.
select * from SENTRY_DB_PRIVILEGE;
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
|DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
|1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
|2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
|3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
|6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
|10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx:8020/user/test2|insert|1579277701218|N|
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
Interestingly, this doesn't show up immediately. I suspect there's some caching going on somewhere. SHOW GRANT ROLE still show ALL for the URI. However, if we make an unrelated change:
revoke all on database default from role testrole2;
SHOW GRANT ROLE now shows the "bad" insert entry.
scope database table column uri privilege grant_option create_time
1 uri hdfs://xxxxx:8020/user/test2 insert false Fri, Jan 17 2020 08:15:01.218
2 table default customers all false Fri, Jan 17 2020 07:34:37.113
The invalid entry causes some strange behaviours. First (fairly expected) the grant itself doesn't work, and customer gets error like:
User gnhlxemcg02 does not have privileges for CREATETABLE
The required privileges: Server=server1->URI=hdfs://xxxxxxxxxxxxxxxxxxxxxxxxxxxx->action=*->grantOption=false; (state=42000,code=40000)
So based on the error, we do what the customer did, and do the grant again:
grant all on uri /user/test2 to role testrole2;
select * from SENTRY_DB_PRIVILEGE;
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
|DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
|1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
|2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
|3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
|6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
|10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxx:8020/user/test2|insert|1579277701218|N|
|11|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx8020/user/test2| |1579278289398|N|
+-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
So now we see TWO entries one with insert, one with *. For the customer only the first seems active, so even though both are in the DB the permission is inefffective.
the "bad" permission can't be revoked, as sentry doesn;t understand URIs with insert:
revoke insert on uri '/user/test2' from testrole2;
AnalysisException: Only 'ALL' privilege may be applied at URI scope in privilege spec
This is not correct behaviour. Revoking select should not change URI grants to insert. I suspect the same is true of revoking insert will leave select. Such "bad" entries are incorrect and cause problems, and are hard to remove.
was:
Revoking "SELECT" permission at the server level changes URI grants from ALL to INSERT, breaking them.
Create a role and assign some permissions:
create role testrole2;
grant all on URI '/user/test2' to role testrole2;
grant all on table customers to role testrole2;
show grant role testrole2;
SHOW GRANT ROLE show expected permissions.
scope database table column uri privilege grant_option create_time
1 uri hdfs://xxxxxx:8020/user/test2 all false Fri, Jan 17 2020 08:13:14.746
2 table default customers all false NULL
Revoke select at the server level
revoke select on server server1 from role testrole2;
In the database, we see the ACTION of the URI has been changed to insert, which is invalid. You can't (manually) create a URI like this.
select * from SENTRY_DB_PRIVILEGE;
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
|DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
|1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
|2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
|3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
|6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
|10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx:8020/user/test2|insert|1579277701218|N|
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
Interestingly, this doesn't show up immediately. I suspect there's some caching going on somewhere. SHOW GRANT ROLE still show ALL for the URI. However, if we make an unrelated change:
revoke all on database default from role testrole2;
SHOW GRANT ROLE now shows the "bad" insert entry.
scope database table column uri privilege grant_option create_time
1 uri hdfs://xxxxx:8020/user/test2 insert false Fri, Jan 17 2020 08:15:01.218
2 table default customers all false Fri, Jan 17 2020 07:34:37.113
The invalid entry causes some strange behaviours. First (fairly expected) the grant itself doesn't work, and customer gets error like:
User gnhlxemcg02 does not have privileges for CREATETABLE
The required privileges: Server=server1->URI=hdfs://hanameservice/data/helix/modelled/common/sanity_demo->action=*->grantOption=false; (state=42000,code=40000)
So based on the error, we do what the customer did, and do the grant again:
grant all on uri /user/test2 to role testrole2;
select * from SENTRY_DB_PRIVILEGE;
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
|DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
|1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
|2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
|3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
|6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
|10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxx:8020/user/test2|insert|1579277701218|N|
|11|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx8020/user/test2| |1579278289398|N|
+------------------+----------------++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------+
So now we see TWO entries one with insert, one with *. For the customer only the first seems active, so even though both are in the DB the permission is inefffective.
the "bad" permission can't be revoked, as sentry doesn;t understand URIs with insert:
revoke insert on uri '/user/test2' from testrole2;
AnalysisException: Only 'ALL' privilege may be applied at URI scope in privilege spec
This is not correct behaviour. Revoking select should not change URI grants to insert. I suspect the same is true of revoking insert will leave select. Such "bad" entries are incorrect and cause problems, and are hard to remove.
> Revoking select at server level corrupts URI grants
> ---------------------------------------------------
>
> Key: SENTRY-2551
> URL: https://issues.apache.org/jira/browse/SENTRY-2551
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
> Affects Versions: 1.5.1
> Reporter: Tony Hill
> Priority: Major
>
> Revoking "SELECT" permission at the server level changes URI grants from ALL to INSERT, breaking them.
>
> Create a role and assign some permissions:
> create role testrole2;
> grant all on URI '/user/test2' to role testrole2;
> grant all on table customers to role testrole2;
> show grant role testrole2;
> SHOW GRANT ROLE show expected permissions.
> scope database table column uri privilege grant_option create_time
> 1 uri hdfs://xxxxxx:8020/user/test2 all false Fri, Jan 17 2020 08:13:14.746
> 2 table default customers all false NULL
> Revoke select at the server level
> revoke select on server server1 from role testrole2;
> In the database, we see the ACTION of the URI has been changed to insert, which is invalid. You can't (manually) create a URI like this.
> select * from SENTRY_DB_PRIVILEGE;
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> |DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> |1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
> |2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
> |3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
> |6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
> |10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx:8020/user/test2|insert|1579277701218|N|
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> Interestingly, this doesn't show up immediately. I suspect there's some caching going on somewhere. SHOW GRANT ROLE still show ALL for the URI. However, if we make an unrelated change:
> revoke all on database default from role testrole2;
> SHOW GRANT ROLE now shows the "bad" insert entry.
> scope database table column uri privilege grant_option create_time
> 1 uri hdfs://xxxxx:8020/user/test2 insert false Fri, Jan 17 2020 08:15:01.218
> 2 table default customers all false Fri, Jan 17 2020 07:34:37.113
> The invalid entry causes some strange behaviours. First (fairly expected) the grant itself doesn't work, and customer gets error like:
> User gnhlxemcg02 does not have privileges for CREATETABLE
> The required privileges: Server=server1->URI=hdfs://xxxxxxxxxxxxxxxxxxxxxxxxxxxx->action=*->grantOption=false; (state=42000,code=40000)
> So based on the error, we do what the customer did, and do the grant again:
> grant all on uri /user/test2 to role testrole2;
> select * from SENTRY_DB_PRIVILEGE;
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> |DB_PRIVILEGE_ID|PRIVILEGE_SCOPE|SERVER_NAME|DB_NAME|TABLE_NAME|COLUMN_NAME|URI|ACTION|CREATE_TIME|WITH_GRANT_OPTION|
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> |1|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__| |1579268899479|N|
> |2|DATABASE|server1|default|__NULL__|__NULL__|__NULL__| |1579268905065|N|
> |3|SERVER|server1|__NULL__|__NULL__|__NULL__|__NULL__|refresh|1579268960929|N|
> |6|TABLE|server1|default|customers|__NULL__|__NULL__|all|1579275277113|N|
> |10|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxx:8020/user/test2|insert|1579277701218|N|
> |11|URI|server1|__NULL__|__NULL__|__NULL__|hdfs://xxxxxx8020/user/test2| |1579278289398|N|
> +-------------------+---------------+++-----------------------++-------------------------++---------------------------------------------------------------------++----------------------------------
> So now we see TWO entries one with insert, one with *. For the customer only the first seems active, so even though both are in the DB the permission is inefffective.
> the "bad" permission can't be revoked, as sentry doesn;t understand URIs with insert:
> revoke insert on uri '/user/test2' from testrole2;
> AnalysisException: Only 'ALL' privilege may be applied at URI scope in privilege spec
> This is not correct behaviour. Revoking select should not change URI grants to insert. I suspect the same is true of revoking insert will leave select. Such "bad" entries are incorrect and cause problems, and are hard to remove.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)