Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Mon, 9 Dec 2013 22:46:07 +0000 (UTC)
From: "Sushanth Sowmyan (JIRA)" <jira@apache.org>
To: hive-dev@hadoop.apache.org
Message-ID: <JIRA.12683702.1386628556586.5794.1386629167745@arcas>
In-Reply-To: <JIRA.12683702.1386628556586@arcas>
References: <JIRA.12683702.1386628556586@arcas>
Subject: [jira] [Updated] (HIVE-5989) Hive metastore authorization check is
 not threadsafe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HIVE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sushanth Sowmyan updated HIVE-5989:
-----------------------------------

    Description: 
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)


  was:
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.


> Hive metastore authorization check is not threadsafe
> ----------------------------------------------------
>
>                 Key: HIVE-5989
>                 URL: https://issues.apache.org/jira/browse/HIVE-5989
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore, Security
>    Affects Versions: 0.11.0
>            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
(v6.1.4#6159)