ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RANGER-768) Hive Metastore Plugin
Date Mon, 11 Jan 2016 18:59:39 GMT

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

Yan commented on RANGER-768:

[~bosco] Thanks for your questions. My answers are as follow:

1. The Admin

2. yes

3 & 4. Admin

Note that the Admin will be the actual executor of the changes on the derived HDFS policies,
these actions could be trigged either from Hive SQL
commands or from the Admin Hive policy management operations. For the latter, an exhaustive
search will probably be launched to find all to-be-affected
derived HDFS policies and make adjustments on them if appropriate. Note that this exhaustive
search will be performed at policy modification and not at query time for the sake of performance.

Also note that there will be some prominent features of the derived HDFS policies:

1) They are simple policies in that no pattern/deny are used, but policy items will be copied
from the driving Hive policy, and the recursive flag can be used
2) They are not modifiable manually except from Admin and by the changes of the driving Hive
policy changes.
3) Other HDFS policies that may affect the same storage locations of the derived policies
may play a role in determining the eventual decision of the access privilege on the storage

On the other hand, I guess I am probably getting your idea behind the proposed "RangerImpliedPolicyResource"
and its "resources" field. Please correct me if I am wrong. You are trying to establish a
"soft link" between a Hive policy and its derived HDFS policy where the evaluation of the
policy  will be performed by the HDFS plugin at query time. If true, my comments are:

1) It's impossible to automatically derive a pattern in the "resources" of the "implied policy
resource" from a pattern in the resources of the driving Hive policy.
2) If the "resources" are to be set up manually, then the SQL table creation/alternation would
possibly need to handle a "mismatched storage" exception that would be unnatural for a SQL
3) If it is agreed that the "resources" field is unnecessary, but the "RangerImpliedPolicyResource"
is to be used by the HDFS plugin, the "exhaustive search" mentioned above may need to be performed
at query time, which in my opinion would have performance concerns.

> 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, 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

View raw message