[
https://issues.apache.org/jira/browse/HIVE-25695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Maheshwari updated HIVE-25695:
-------------------------------------
Description:
HIVE-24026 introduced an authorization model where views created from external
sources like spark are not authorized at create time, but when a user does
select on the view. We need to make this authorization configurable.
This Jira introduces a new config to make this auth model configurable.
{code:java}
hive.security.authorization.enabled.on.spark.views=true {code}
This config is turned on by default. If the users wish to turn off this config,
then they can set this config to false, which means that during the select
query, the underlying tables for that view will not be authorized.
The reason for making this auth model configurable is because there can be a
use-case where a user is running workload of create/alter/select views without
HIVE-24026 (with ranger/sentry policies in place where user have select
permissions only on view but not on underlying tables) and when user upgrades
to HIVE-24026, the admin will have to configure ranger/sentry policies on all
the underlying tables for required users. By simply turning off this config,
the user can do workload operations but at the cost of the security hole for
not authorizing the underlying tables.
was:
HIVE-24026 introduced an authorization model where views created from external
sources like spark are not authorized at create time, but when a user does
select on the view. We need to make this authorization configurable.
This Jira introduces a new config to make this auth model configurable.
{code:java}
hive.security.authorization.enabled.on.spark.views=true {code}
This config is turned on by default. If the users wish to turn off this config,
then they can set this config to false, which means that during the select
query, the underlying tables for that view will not be authorized.
The reason for making this auth model configurable is because there can be a
use-case where a user is running workload of create/alter/select views without
HIVE-24026 (with ranger/sentry policies in place where user have select
permissions only on view but not on underlying tables) and when user upgrades
to HIVE-24026, the admin will have to configure ranger/sentry policies on all
the underlying tables for required users. By simply turning off this config,
the user can do workload operations but at the cost of the security hole for
not authorizing the underlying tables.
> Make spark views authorization in hive configurable.
> ----------------------------------------------------
>
> Key: HIVE-25695
> URL: https://issues.apache.org/jira/browse/HIVE-25695
> Project: Hive
> Issue Type: Improvement
> Components: HiveServer2
> Reporter: Sai Hemanth Gantasala
> Assignee: Sai Hemanth Gantasala
> Priority: Major
> Labels: pull-request-available
> Fix For: 4.0.0-alpha-1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> HIVE-24026 introduced an authorization model where views created from
> external sources like spark are not authorized at create time, but when a
> user does select on the view. We need to make this authorization
> configurable.
> This Jira introduces a new config to make this auth model configurable.
> {code:java}
> hive.security.authorization.enabled.on.spark.views=true {code}
> This config is turned on by default. If the users wish to turn off this
> config, then they can set this config to false, which means that during the
> select query, the underlying tables for that view will not be authorized.
> The reason for making this auth model configurable is because there can be a
> use-case where a user is running workload of create/alter/select views
> without HIVE-24026 (with ranger/sentry policies in place where user have
> select permissions only on view but not on underlying tables) and when user
> upgrades to HIVE-24026, the admin will have to configure ranger/sentry
> policies on all the underlying tables for required users. By simply turning
> off this config, the user can do workload operations but at the cost of the
> security hole for not authorizing the underlying tables.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
