You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Don Bosco Durai (JIRA)" <ji...@apache.org> on 2016/01/05 05:17:39 UTC

[jira] [Commented] (RANGER-768) Hive Metastore Plugin

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

Don Bosco Durai commented on RANGER-768:
----------------------------------------

[~yzhou2001], thanks for putting together this document. Do you want to convert this to a Wiki page in Ranger, so it will be easy for you to edit and also it will be easier for us to give feedback.

First of all this is looking good. Here are my initial feedback. It would be good if [~madhan.neethiraj] also reviews it. He is more familiar with the Ranger Hive plugin.

bq. 2.2.1 - And the two listeners can optionally enable auditing
Audit should be implicitly enabled as part of Ranger plugin

bq. 2.2.3 - Range HDFS Privilege Changes..
I feel we should discuss this in the mailing list. My suggestion would be to create these Ranger policies for HDFS which references back to the Hive Database/Table policy. So if the policy changes, we can easily find the corresponding HDFS policies and update them. Also, these HDFS policies shouldn't be editable outside the context of Hive. We can make it generic that the design can be used for any other component (e.g. Spark) also.

bq. The policy will be for the login user on the HDFS directories on the object’s storage location recursively if the login user is different from the current user
I like this. This will simplify the number of policies

bq. Ranger Hive Plugin is only enabled for the HiveServer2 so the Hive CLI does not see corresponding Ranger policies being adjusted as result of Hive GRANT/REVOKE calls
I am not sure whether HiveCLI supports GRANT/REVOKE

bq. The RangerServiceREST’s grant/revokeAccess methods will handle the policy adjustments as is now, even though the requests could come from both the existing Hive plugin and the new Hive metastore plugin.
By Hive metastore plugin, do you mean HiveCLI?

bq. In the tables, “listener” denotes “MetaStorePreEventListener; “Authorizer” denotes “HiveAuthorizer”; “x” means no invocation at all; “*” means “seemingly always being denied before possibly proceed further”.
Can you clarify what you mean here?

Thanks

> Hive Metastore Plugin
> ---------------------
>
>                 Key: RANGER-768
>                 URL: https://issues.apache.org/jira/browse/RANGER-768
>             Project: Ranger
>          Issue Type: New Feature
>          Components: admin, plugins
>            Reporter: Yan
>         Attachments: Design Proposal for Hive Metastore Plugin of Ranger.docx
>
>
> Currently there is no Ranger processing of Hive table meta store events that could result in privilege modifications. One example is that when a table is renamed by a Hive Server 2 client (the "beeline"), no proper privilege adjustments in Ranger are made to allow/deny previously allowed/denied users the same privileges as before. In addition, more advanced features, such as granting/denying similar accesses to Hive's HDFS data to users that have (or do not have) privileges in the Hive, would require that detailed metadata of the Hive table, the storage info to be specific, be available to Ranger in order to make the corresponding HDFS  data accessible to the Hive users directly.
> This plugin will depend upon the existing Ranger Hive plugin, so it shares the same "service" name as the associated Ranger Hive service deployed, and it will be "co-enabled" with the existing Ranger Hive plugin.
> Design doc will come soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)