[
https://issues.apache.org/jira/browse/RANGER-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15098658#comment-15098658
]
Yan commented on RANGER-768:
----------------------------
[~avd251] I modified the doc with a use case for the "prohibitive" approach.
Other comments are as follows:
1) The "hive" user already has the required permission to the warehouse folder
in HDFS => Yes. But it is controlled by HDFS's native access privileges and not
reflected in Ranger policies I believe. If we do not require "hive" to have the
"admin" privilege in Ranger but still allow him to implicitly create/ HDFS
policies, I am afraid of any security holes. I'm open on further discussions
and would like to hear advices from you guys.
2) When I said "Hive service name as the existing Hive plugin", it might be a
bit misleading in that the two services of the same name are implied. I'm sorry
for that confusion. But it actually mean the same service that is going to
handle requests from two Hive plugins sequentially. It is conceivable that the
requests from the two plugins may have some functional overlapping. For
instance, the same authorization on the same resource from a single SQL could
be checked against the two hooks sequentially. This is decided by Hive,
probably due to considerations to pay a bit performance for a solid strong
security.
3) As for the existing table and partitions, this is a good question and thanks
for catching. Since the whole HDFS policy sync is trigged and driven by SQL DDL
commands, I guess it'd be difficult to support. One approach could be to let
the refresher to access Hive Metastores, fetch and parse out the storage
information. It would, however, probably require Hive to open up some of its
internal data structures and/or methods. There are two workarounds though: i)
recreate the table, or ii) manually add the derived HDFS policies. And we can
document this as a limitation and suggest the possible workarounds. Please let
me know what you think.
4) For the "state diagram", could you elaborate a bit on what processing and
its states you'd like to see in such diagrams?
5) If you don't mind, we can continue discussion here which seems to be near a
conclusion. I'm not feeling comfortable with Wiki authoring yet.
6) "How are we planning to send the HDFS resources associated with the policy?"
=> from the plugin send a table's storage info to Admin. The Hive hooks will
pass the storage info to the plugin.
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 -
> V1.2.docx, Design Proposal for Hive Metastore Plugin of Ranger - V1.3.docx,
> 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)
