[jira] [Created] (SENTRY-2551) Revoking select at server level corrupts URI grants

["Tony Hill (Jira)" <ji...@apache.org>]

Tony Hill created SENTRY-2551:
---------------------------------

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


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.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)