ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Bosco Durai (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-768) Hive Metastore Plugin
Date Tue, 05 Jan 2016 04:17:39 GMT

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

Mime
View raw message