[
https://issues.apache.org/jira/browse/HIVE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652162#action_12652162
]
Edward Capriolo commented on HIVE-78:
-------------------------------------
Recursive Role processing is probably not possible with JDBCRealm.
Recursive Role processing is generally difficult to implement. N.I.S. Net
Groups is an example of this, because of the recursive nature you have a more
complicated implementation. Firstly, you have to check for loops in the group
definition. Role1 memberOf-> Role2-> memberOf Role3-> memberOf ->Role1. This
needs to be done when the rule is created, or evaluated, or both. I have found
(in my experience) dynamic/recursive groups are are less practical then they
originally seem. They do have merit however.
The roles you mentioned were:
* SELECT
* INSERT
* ALTER TABLE
* CREATE
* DROP
* KILL SESSION(QUERY)
* SHUTDOWN
* STARTUP
* VIEW SESSIONS
IMPORTANT: Are roles global or per object? Realms really only make sense with
global permissions.
Lets look at a scenario:
* Hive
** tableA
** tableB
** tableC
* Users
** john
*** uid 3000
*** gid 3000,4000
** bob
*** uid 3001
*** gid 3001,4000
* Groups
** john
*** gid 3000
** bob
*** gid 3001
** hr
*** gid 4000
Goal to implement root has full access to all tables, john has access to table
a, and bob has access to table b. tablec can be read by anyone in hr
* Realms
** tableA_select
*** root
*** john
** tableA_insert
*** root
*** john
** tableB_select
*** root
*** bob
** tableB_insert
*** root
*** bob
** tableC_select
*** root
*** bob
*** john
Using '_' as a delimiter and constructing several roles per table is a slightly
non standard for realms, but it would work. User lists are flat.
About these permissions:
* SELECT
* INSERT
* ALTER TABLE
* CREATE
* DROP
If an external table was created. If my UID has access to the file through HDFS
I would expect to have select access inside Hive. If I could not write the file
in HDFS hive would not expect hive to give me these permissions. I think we
should clearly define the difference between AUTHENTICATION and ACCESS.
For example, the AUTHENTICATION information for a user is commonly stored in
Active Directory. However ACCESS information like, what tables a user may run
SELECT on can not be stored in Active Directory without changing the Active
Directory schema.
Realm or JAAS gives us a quick way to answer the authorization question. As to
the ACCESS we either have to store that information in the meta store or an
external system.
> Authentication infrastructure for Hive
> --------------------------------------
>
> Key: HIVE-78
> URL: https://issues.apache.org/jira/browse/HIVE-78
> Project: Hadoop Hive
> Issue Type: New Feature
> Components: Server Infrastructure
> Reporter: Ashish Thusoo
> Assignee: Edward Capriolo
>
> Allow hive to integrate with existing user repositories for authentication
> and authorization infromation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
