hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-78) Authentication infrastructure for Hive
Date Fri, 18 Sep 2009 14:27:16 GMT

    [ https://issues.apache.org/jira/browse/HIVE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12757179#action_12757179
] 

Edward Capriolo commented on HIVE-78:
-------------------------------------

@Min
(this may be somewhat mistated but) Hadoop-Core gets the user/group information for a posix
user by running shell commands like,
WHOAMI, GROUPS, ID, etc. The hive CLI will inherit this information as does HiveServer, HWI.

The hive web interface starts as the user sho ran the start script. The first screen on the
web interface is a defacto log-in screen. This allows the user to enter their user and group
information in text boxes. 

When HWI starts the session on behalf of the user it runs "SET hadoop.ugi={what user entered
in the test box}" at that point if the user initiates a hive job, the output of that job should
be files owned by that user. I am pretty sure the code in QL just chown's the files at job
end or perhaps the entire job runs as that user (I cant remember).

My comment above is just referencing the fact that in some cases Hadoop ACL and our Hive authorization
rules would conflict. IE
If the files were owned by mzhou. "saying grant delete to * user edward" would not give me
privileges to drop files you owned. In that case sections of the HiveServer would have to
run as superuser to elevate privileges, but we punted on that issue too. (We are like a football
team with bad offense. always punting)

(If we were going to tackle password we could do it in this way)
I would think if we wanted to enforce strong user/password authentication we could do this


{noformat}
<property>
   <name>hive.password.insession</true>
  <value>hive_password</value>
  <description>empty for no password checking, if defined this is the session variable
to look for password"</descripton>
</property>
{noformat}

In this way QL would read this value and would not execute any task for the user unless they
had  run "set hive_password=XYXYXYY"

Does that make sense? Session already holds the user. It could hold the password as well.
Do you see anything wrong with that approach?

I will trim down some of the stuff I have and get upload it for reference



> 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
>         Attachments: hive-78-metadata-v1.patch, hive-78-syntax-v1.patch, hive-78.diff
>
>
> 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.


Mime
View raw message