[
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
