[
https://issues.apache.org/jira/browse/HIVE-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747010#comment-13747010
]
Sushanth Sowmyan commented on HIVE-3591:
----------------------------------------
Good spot, Larry. That's one more thing to address about client-side
authorization, and much more basic than the issue of any user being able to
grant themselves permissions for anything. :D
[~ashutoshc] mentions that we have a notion of restrict-lists for HiveServer2,
wherein it rejects attempts wherein users try set commands on restricted config
parameters, and it might be a good idea to extend that notion to the hive
client as well.
It still leaves open the case where the end user is able to edit their
hive-site.xml to simply set the parameter there, rather than in-script or
in-commandline, but that is protectable by admin policies for deployments, and
might be a reasonable compromise.
That said, all of these still leave open the notion of being able edit/compile
hive sources leaving out these protections on the client side, and thus, your
metadata is not truly secure (data can be made secure by hdfs perms) unless
you're using metastore-side authorization.
> set hive.security.authorization.enabled can be executed by any user
> -------------------------------------------------------------------
>
> Key: HIVE-3591
> URL: https://issues.apache.org/jira/browse/HIVE-3591
> Project: Hive
> Issue Type: Bug
> Components: Authorization, CLI, Clients, JDBC
> Affects Versions: 0.7.1
> Environment: RHEL 5.6
> CDH U3
> Reporter: Dev Gupta
> Labels: Authorization, Security
>
> The property hive.security.authorization.enabled can be set to true or false,
> by any user on the CLI, thus circumventing any previously set grants and
> authorizations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
