[SENTRY-2551] Revoking select at server level corrupts URI grants

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.5.1
• Component/s: Sentry
• Assignee: Unassigned
• Reporter: Tony Hill
• Created: 18/Feb/20 09:51
• Updated: 18/Feb/20 09:53

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