Return-Path: X-Original-To: apmail-hive-dev-archive@www.apache.org Delivered-To: apmail-hive-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4F9281092B for ; Wed, 21 Aug 2013 23:31:54 +0000 (UTC) Received: (qmail 62091 invoked by uid 500); 21 Aug 2013 23:31:53 -0000 Delivered-To: apmail-hive-dev-archive@hive.apache.org Received: (qmail 62021 invoked by uid 500); 21 Aug 2013 23:31:53 -0000 Mailing-List: contact dev-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hive.apache.org Delivered-To: mailing list dev@hive.apache.org Received: (qmail 61977 invoked by uid 500); 21 Aug 2013 23:31:53 -0000 Delivered-To: apmail-hadoop-hive-dev@hadoop.apache.org Received: (qmail 61963 invoked by uid 99); 21 Aug 2013 23:31:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Aug 2013 23:31:53 +0000 Date: Wed, 21 Aug 2013 23:31:53 +0000 (UTC) From: "Sushanth Sowmyan (JIRA)" To: hive-dev@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HIVE-3591) set hive.security.authorization.enabled can be executed by any user MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HIVE-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747019#comment-13747019 ] Sushanth Sowmyan commented on HIVE-3591: ---------------------------------------- [~lmccay] : I wouldn't say "resolved", per se - the issue you bring is a valid one, but one that does not fit the original hive security design (designed to prevent people from accidentally doing something dangerous, as opposed to being designed to prevent malicious users). For the security-conscious, there is currently a work-around(metastore-side security) for the intermediate case where stronger security is needed. I think this is an important data point though, for us to consider when trying to nail down hive security, and there is some intermediate work possible for this in the short run as well(the above restricted conf idea) > set hive.security.authorization.enabled can be executed by any user > ------------------------------------------------------------------- > > Key: HIVE-3591 > URL: https://issues.apache.org/jira/browse/HIVE-3591 > Project: Hive > Issue Type: Bug > Components: Authorization, CLI, Clients, JDBC > Affects Versions: 0.7.1 > Environment: RHEL 5.6 > CDH U3 > Reporter: Dev Gupta > Labels: Authorization, Security > > The property hive.security.authorization.enabled can be set to true or false, by any user on the CLI, thus circumventing any previously set grants and authorizations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira