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 Thu, 14 Jan 2016 19:14:39 GMT

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

Mime
View raw message