Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4B4A310B15 for ; Sat, 21 Dec 2013 00:50:10 +0000 (UTC) Received: (qmail 30939 invoked by uid 500); 21 Dec 2013 00:50:10 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 30852 invoked by uid 500); 21 Dec 2013 00:50:10 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 30844 invoked by uid 99); 21 Dec 2013 00:50:10 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Dec 2013 00:50:10 +0000 Date: Sat, 21 Dec 2013 00:50:09 +0000 (UTC) From: "Gary Helmling (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints 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/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854714#comment-13854714 ] Gary Helmling commented on HBASE-6104: -------------------------------------- Sorry my example wasn't very clear. I meant the "*" to represent the username, so effectively doing a default allow to all users. Don't think we support this yet? Certain combinations would still be problematic -- if I grant to "*" users, then try to revoke for a single user is that allowed or does it error out? > Require EXEC permission to call coprocessor endpoints > ----------------------------------------------------- > > Key: HBASE-6104 > URL: https://issues.apache.org/jira/browse/HBASE-6104 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security > Affects Versions: 0.95.2 > Reporter: Gary Helmling > Assignee: Andrew Purtell > Fix For: 0.98.0 > > Attachments: 6104.patch > > > The EXEC action currently exists as only a placeholder in access control. It should really be used to enforce access to coprocessor endpoint RPC calls, which are currently unrestricted. > How the ACLs to support this would be modeled deserves some discussion: > * Should access be scoped to a specific table and CoprocessorProtocol extension? > * Should it be possible to grant access to a CoprocessorProtocol implementation globally (regardless of table)? > * Are per-method restrictions necessary? > * Should we expose hooks available to endpoint implementors so that they could additionally apply their own permission checks? Some CP endpoints may want to require READ permissions, others may want to enforce WRITE, or READ + WRITE. > To apply these kinds of checks we would also have to extend the RegionObserver interface to provide hooks wrapping HRegion.exec(). -- This message was sent by Atlassian JIRA (v6.1.4#6159)