hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (JIRA)" <>
Subject [jira] [Commented] (HIVE-5989) Hive metastore authorization check is not threadsafe
Date Mon, 09 Dec 2013 23:56:08 GMT


Hive QA commented on HIVE-5989:

{color:red}Overall{color}: -1 at least one tests failed

Here are the results of testing the latest attachment:

{color:red}ERROR:{color} -1 due to 2 failed/errored test(s), 4761 tests executed
*Failed tests:*

Test results:
Console output:

Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
Tests exited with: TestsFailedException: 2 tests failed

This message is automatically generated.


> Hive metastore authorization check is not threadsafe
> ----------------------------------------------------
>                 Key: HIVE-5989
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore, Security
>    Affects Versions: 0.11.0, 0.12.0, 0.12.1
>            Reporter: Sushanth Sowmyan
>            Assignee: Sushanth Sowmyan
>            Priority: Critical
>         Attachments: HIVE-5989.patch, SleepyAP.patch
> Metastore-side authorization has a couple of pretty important threadsafety bugs in it:
> a) The HiveMetastoreAuthenticated instantiated by the AuthorizationPreEventListener is
static. This is a premature optimization and incorrect, as it will result in Authenticator
implementations that store state potentially giving an incorrect result, and this bug very
much exists with the DefaultMetastoreAuthenticator.
> b) It assumes HMSHandler.getHiveConf() is itself going to be thread-safe, which it is
not. HMSHandler.getConf() is the appropriate thread-safe equivalent.
> The effect of this bug is that if there are two users that are concurrently running jobs
on the metastore, we might :
> a) Allow a user to do something they didn't have permission to, because the other person
did. (Security hole)
> b) Disallow a user from doing something they should have permission to (More common -
annoying and can cause job failures)

This message was sent by Atlassian JIRA

View raw message