[
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)
