[
https://issues.apache.org/jira/browse/RANGER-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15089998#comment-15089998
]
Yan commented on RANGER-768:
----------------------------
Note that the Hive handling by the Admin is the driver for the "derived" HDFS
policies. Given this, I can see
1) Only the mapping from a Hive policy to the derived HDFS policy is necessary
in a Hive Policy. The original design uses the policy name pattern of the
derived HDFS policy to implicitly establish this mapping, which smells like a
hacking but with an advantage of simplicity. Use of a pair of (policy id,
resourceService) will serve the purpose of mapping better and more natural at
the cost of more complexity. I am open to either option. The "resourceService"
is a better name than the original "storageServiceName". But I don't see the
need of the field of "Map<String, RangerPolicyResource> resources"
2) For the HIve-derived HDFS policies, I think it should be made
"non-modifiable" except from the driving Hive policy change processing, namely
it should not be modified/added/deleted by a normal user. For this, a new
boolean field of "modifiable" will be added to the policy; and GUI support will
be added to disallow manual modification of the "unmodifiable" policies.
> 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
(v6.3.4#6332)
