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

Hive QA commented on HIVE-5987:
-------------------------------



{color:green}Overall{color}: +1 all checks pass

Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12617800/HIVE-5987.1.patch

{color:green}SUCCESS:{color} +1 4761 tests passed

Test results: 
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/576/testReport
Console output: 
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/576/console

Messages:
{noformat}
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}

This message is automatically generated.

ATTACHMENT ID: 12617800

> The secure metastore service should reject connection from users that it 
> can't impersonate
> ------------------------------------------------------------------------------------------
>
>                 Key: HIVE-5987
>                 URL: https://issues.apache.org/jira/browse/HIVE-5987
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore, Security
>    Affects Versions: 0.12.0
>            Reporter: Prasad Mujumdar
>            Assignee: Prasad Mujumdar
>         Attachments: HIVE-5987.1.patch
>
>
> The secure metastore always doesn't allow any client to connect without a 
> valid kerberos ticket. Also the client requests are executed by impersonating 
> the requesting userid. If metastore principal doesn't have privileges to 
> impersonate the connecting user, then the DDL operations (eg create table, 
> partition etc) will fail. However any user with valid Kerberos ticket is can 
> connect to metastore service and perform read-only metadata operations. For 
> example, get list of databases, tables; properties of each table like HDFS 
> location, file type etc.
> The secure metastore behavior should be consistent. If a the metastore server 
> doesn't have privileges to impersonate the connecting user, then it should 
> reject connection.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Reply via email to