[
https://issues.apache.org/jira/browse/HIVE-13198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Haihua updated HIVE-13198:
-------------------------------
Description:
dHere is a use case. They have a base table t1, from which they create a view
v1. They further create a view v2 from v1 by applying a filter. User has access
to only view v2, not view v1 or table t1. When user tries to access v2, they
are denied access.
Steps to recreate:
There is a base table t1 that exists in the default database with primary key
id and some employee data (name, ssn etc)
Create view v1 - “create view v1 as select * from default.t1;”
Created v2 - “create view v2 as select * from v1 where id =1;”
Permissions provided for user to select all columns from view v2. When user
runs select * from v2, hive throws an error “user does not have permissions to
select view v1".
Apparently Hive is converting the query to underlying views.
SELECT * FROM v2 LIMIT 100
To
select `v1`.`id`, `v1`.`name`, `v1`.`ssn`, `v1`.`join_date`, `v1`.`location`
from `hr`.`v1` where `v1`.`id`=1
Hive should only check for permissions for the view being run in the query, not
any parent views. (This is consistent with ORACLE).
was:
Here is a use case. They have a base table t1, from which they create a view
v1. They further create a view v2 from v1 by applying a filter. User has access
to only view v2, not view v1 or table t1. When user tries to access v2, they
are denied access.
Steps to recreate:
There is a base table t1 that exists in the default database with primary key
id and some employee data (name, ssn etc)
Create view v1 - “create view v1 as select * from default.t1;”
Created v2 - “create view v2 as select * from v1 where id =1;”
Permissions provided for user to select all columns from view v2. When user
runs select * from v2, hive throws an error “user does not have permissions to
select view v1".
Apparently Hive is converting the query to underlying views.
SELECT * FROM v2 LIMIT 100
To
select `v1`.`id`, `v1`.`name`, `v1`.`ssn`, `v1`.`join_date`, `v1`.`location`
from `hr`.`v1` where `v1`.`id`=1
Hive should only check for permissions for the view being run in the query, not
any parent views. (This is consistent with ORACLE).
> Authorization issues with cascading views
> -----------------------------------------
>
> Key: HIVE-13198
> URL: https://issues.apache.org/jira/browse/HIVE-13198
> Project: Hive
> Issue Type: Sub-task
> Reporter: Pengcheng Xiong
> Assignee: Pengcheng Xiong
> Fix For: 2.1.0
>
> Attachments: HIVE-13198.01.patch, HIVE-13198.02.patch
>
>
> dHere is a use case. They have a base table t1, from which they create a view
> v1. They further create a view v2 from v1 by applying a filter. User has
> access to only view v2, not view v1 or table t1. When user tries to access
> v2, they are denied access.
> Steps to recreate:
> There is a base table t1 that exists in the default database with primary key
> id and some employee data (name, ssn etc)
> Create view v1 - “create view v1 as select * from default.t1;”
> Created v2 - “create view v2 as select * from v1 where id =1;”
> Permissions provided for user to select all columns from view v2. When user
> runs select * from v2, hive throws an error “user does not have permissions
> to select view v1".
> Apparently Hive is converting the query to underlying views.
> SELECT * FROM v2 LIMIT 100
> To
> select `v1`.`id`, `v1`.`name`, `v1`.`ssn`, `v1`.`join_date`, `v1`.`location`
> from `hr`.`v1` where `v1`.`id`=1
> Hive should only check for permissions for the view being run in the query,
> not any parent views. (This is consistent with ORACLE).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
