Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 5AFA1200C30 for ; Tue, 7 Mar 2017 20:49:44 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 59A26160B68; Tue, 7 Mar 2017 19:49:44 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A942D160B65 for ; Tue, 7 Mar 2017 20:49:43 +0100 (CET) Received: (qmail 12501 invoked by uid 500); 7 Mar 2017 19:49:42 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 12490 invoked by uid 99); 7 Mar 2017 19:49:42 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Mar 2017 19:49:42 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 6785DC0C69 for ; Tue, 7 Mar 2017 19:49:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.652] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id OoApeRvOh1Ym for ; Tue, 7 Mar 2017 19:49:41 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 0991E5F297 for ; Tue, 7 Mar 2017 19:49:41 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D15B9E086A for ; Tue, 7 Mar 2017 19:49:39 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 7714C24192 for ; Tue, 7 Mar 2017 19:49:38 +0000 (UTC) Date: Tue, 7 Mar 2017 19:49:38 +0000 (UTC) From: "Sam Tunnicliffe (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-13053) GRANT/REVOKE on table without keyspace performs permissions check incorrectly MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 07 Mar 2017 19:49:44 -0000 [ https://issues.apache.org/jira/browse/CASSANDRA-13053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900037#comment-15900037 ] Sam Tunnicliffe commented on CASSANDRA-13053: --------------------------------------------- +1 > GRANT/REVOKE on table without keyspace performs permissions check incorrectly > ----------------------------------------------------------------------------- > > Key: CASSANDRA-13053 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13053 > Project: Cassandra > Issue Type: Bug > Components: CQL > Reporter: Sam Tunnicliffe > Assignee: Aleksey Yeschenko > Priority: Minor > Fix For: 2.2.x, 3.0.x, 3.11.x > > > When a {{GRANT}} or {{REVOKE}} statement is executed on a table without specifying the keyspace, we attempt to use the client session's keyspace to qualify the resource. > This is done when validating the statement, which occurs after checking that the user executing the statement has sufficient permissions. This means that the permissions checking uses an incorrect resource, namely a table with a null keyspace. If that user is a superuser, then no error is encountered as superuser privs implicitly grants *all* permissions. If the user is not a superuser, then the {{GRANT}} or {{REVOKE}} fails with an ugly error, regardless of which keyspace the client session is bound to: > {code} > Unauthorized: Error from server: code=2100 [Unauthorized] message="User admin has no AUTHORIZE permission on or any of its parents" > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)