Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
If Hive is configured with an authorization hook like Sentry, and a view is created with a WHERE clause referencing a different view' user has no access to, user cannot access the view as view' is considered direct input.
For example:
create database db1; create database db2; create database db3; create table db1.table1 (cola string, colb string, colc string); insert into db1.table1 values ('a','b','c'); insert into db1.table1 values ('x','y','z'); CREATE VIEW db2.view1 AS SELECT cola, colb, colc FROM db1.table1 WHERE cola="x"; CREATE VIEW db2.view2 AS SELECT table1.cola, table1.colb, table1.colc FROM db1.table1 WHERE table1.cola NOT IN (SELECT view1.cola FROM db2.view1); create view db3.view3 as select * from db2.view2
If test_user has read permission for only db3 (but not db1 or db2), their query
select * from db3.view3;
will fail with :
Error while compiling statement: FAILED: SemanticException No valid privileges User test_user does not have privileges for QUERY The required privileges: Server=server1->Db=db2->Table=view1->action=select;
WHERE IN and WHERE EXISTS cause the same issue.
Cascading views created with no WHERE clauses (i.e. with simple SELECTs and FROM clauses) work fine.
Attachments
Attachments
Issue Links
- relates to
-
HIVE-14805 Subquery inside a view will have the object in the subquery as the direct input
- Closed
- links to