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)