[ https://issues.apache.org/jira/browse/HIVE-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499331#comment-13499331 ]
Sushanth Sowmyan commented on HIVE-3705: ---------------------------------------- @Ashutosh : Funny - I've uploaded a lone patch as well now, just in case something was wrong with the autogeneration. It's called hive-backend-auth.git.patch and can be applied with a patch -p1 @Shreepadma : Thanks for your comments! a) The idea is that the box (or vm/etc) on which the metastore server runs can be secured and given limited login privileges, and kept away from most of the hive users. That way, the "secrets" such as the hive-site.xml that contains the mysql password, and the hive-site.xml config that sets which AuthorizationProvider to use from the metastore is under strict control of the admin. b) I agree that the current model's semantics can sometimes be confusing, especially when you consider separate grant/revoke based permissions and HDFS permissions, and indeed, the authorization provider I intend to use with hive that builds on top of this will be a HDFS-permissions based Authorization Provider, but the hooks for how to launch the Authorization(&Authentication) Providers and what objects they authorize on are good interfaces, I think, and I've merely extended them in where/how they can be invoked in this patch. I think there's a lot of work yet to be done, in cleaning up the privilege definitions in HiveOperation, and making sure that the various authorization calls are actually called. Take, for example the notion that "drop database" does not make any auth calls! So yes, there is more work to be done on this end. I'll be glad to put up a list of other items I felt needed to be changed/fixed. c) The userid for performing authorization is obtained from the provided authenticator. I have an implementation of a default MetastoreAuthenticator with this patch which tries to obtain the userid from the ugi that the HMSHandler has access to. I use this because it makes the most sense as it is as that user that HMSHandler uses to create wh objects, and to perform filesystem calls, for example. I'm afraid I don't know the thrift-side plumbing too well to know where it gets that setting from. As for how it interacts with HS2, again, I don't know how HS2 itself works, but if HS2 is performing a task on behalf of a user, then it would call create_table_core, for eg., as that user. Additional Authentication providers can also be written and plugged in to this scheme - I merely describe how the one I wrote and use works. > Adding authorization capability to the metastore > ------------------------------------------------ > > Key: HIVE-3705 > URL: https://issues.apache.org/jira/browse/HIVE-3705 > Project: Hive > Issue Type: New Feature > Components: Authorization, Metastore > Reporter: Sushanth Sowmyan > Assignee: Sushanth Sowmyan > Attachments: HIVE-3705.D6681.1.patch, HIVE-3705.D6681.2.patch, > hive-backend-auth.git.patch, hivesec_investigation.pdf > > > In an environment where multiple clients access a single metastore, and we > want to evolve hive security to a point where it's no longer simply > preventing users from shooting their own foot, we need to be able to > authorize metastore calls as well, instead of simply performing every > metastore api call that's made. -- 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