[jira] [Commented] (HIVE-25695) Make spark views authorization in hive configurable.

["Naveen Gangam (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-25695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444924#comment-17444924 ] 

Naveen Gangam commented on HIVE-25695:
--------------------------------------

Fix has been pushed to master. Thank you for the fix [~hemanth619]. Closing the jira. 

> 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
>          Time Spent: 10m
>  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.1#820001)