Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 5 Nov 2011 00:19:53 +0000 (UTC)
From: "jiraposter@reviews.apache.org (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1338195103.1845.1320452393234.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-3025) Coprocessor based simple access
 control
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144479#comment-13144479 ] 

jiraposter@reviews.apache.org commented on HBASE-3025:
------------------------------------------------------


bq.  On 2011-11-04 22:29:08, Andrew Purtell wrote:
bq.  > security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java, line 66
bq.  > <https://reviews.apache.org/r/2041/diff/3/?file=55459#file55459line66>
bq.  >
bq.  >     Would 1 slave be sufficient?

Yes, no reason for more than 1.


bq.  On 2011-11-04 22:29:08, Andrew Purtell wrote:
bq.  > security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java, line 87
bq.  > <https://reviews.apache.org/r/2041/diff/3/?file=55460#file55460line87>
bq.  >
bq.  >     Should we wait for the ACL table to become available here?
bq.  >     
bq.  >     I've seen this after making changes that alter connection setup timing:
bq.  >     
bq.  >     org.apache.hadoop.hbase.TableNotFoundException: _acl_
bq.  >     	at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:863)
bq.  >     	at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:732)
bq.  >     	at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:697)
bq.  >     	at org.apache.hadoop.hbase.client.HTable.<init>(HTable.java:196)
bq.  >     	at org.apache.hadoop.hbase.client.HTable.<init>(HTable.java:152)
bq.  >     	at org.apache.hadoop.hbase.security.rbac.TestAccessController.setupBeforeClass(TestAccessController.java:95)

Ok, will make sure we wait until it's available.


- Gary


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/#review3057
-----------------------------------------------------------


On 2011-11-01 21:18:27, Gary Helmling wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2041/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-11-01 21:18:27)
bq.  
bq.  
bq.  Review request for hbase.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  This patch implements access control list based authorization of HBase operations.  The patch depends on the currently posted patch for HBASE-2742 (secure RPC engine).
bq.  
bq.  Key parts of the implementation are:
bq.  
bq.  * AccessControlLists - encapsulates storage of permission grants in a metadata table ("_acl_").  This differs from previous implementation where the ".META." table was used to store permissions.
bq.  
bq.  * AccessController - 
bq.    - implements MasterObserver and RegionObserver, performing authorization checks in each of the preXXX() hooks.  If authorization fails, an AccessDeniedException is thrown.
bq.    - implements AccessControllerProtocol as a coprocessor endpoint to provide RPC methods for granting, revoking and listing permissions.
bq.  
bq.  * ZKPermissionWatcher (and TableAuthManager) - synchronizes ACL entries and updates throughout the cluster nodes using ZK.  ACL entries are stored in per-table znodes as /hbase/acl/tablename.
bq.  
bq.  * Additional ruby shell scripts providing the "grant", "revoke" and "user_permission" commands
bq.  
bq.  * Support for a new OWNER attribute in HTableDescriptor.  I could separate out this change into a new JIRA for discussion, but I don't see it as currently useful outside of security.  Alternately, I could handle the OWNER attribute completely in AccessController without changing HTD, but that would make interaction via hbase shell a bit uglier.
bq.  
bq.  
bq.  This addresses bug HBASE-3025.
bq.      https://issues.apache.org/jira/browse/HBASE-3025
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlFilter.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControllerProtocol.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/TableAuthManager.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/UserPermission.java PRE-CREATION 
bq.    security/src/main/java/org/apache/hadoop/hbase/security/access/ZKPermissionWatcher.java PRE-CREATION 
bq.    security/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java PRE-CREATION 
bq.    security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessControlFilter.java PRE-CREATION 
bq.    security/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java PRE-CREATION 
bq.    security/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java PRE-CREATION 
bq.    security/src/test/java/org/apache/hadoop/hbase/security/access/TestZKPermissionsWatcher.java PRE-CREATION 
bq.    src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 99875b8 
bq.    src/main/java/org/apache/hadoop/hbase/coprocessor/BaseRegionObserver.java 8a40762 
bq.    src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java bb67e53 
bq.    src/main/resources/hbase-default.xml 3785533 
bq.    src/main/ruby/hbase.rb 4d27191 
bq.    src/main/ruby/hbase/admin.rb 61e04d8 
bq.    src/main/ruby/hbase/hbase.rb beb2450 
bq.    src/main/ruby/hbase/security.rb PRE-CREATION 
bq.    src/main/ruby/shell.rb 9a47600 
bq.    src/main/ruby/shell/commands.rb a352c2e 
bq.    src/main/ruby/shell/commands/grant.rb PRE-CREATION 
bq.    src/main/ruby/shell/commands/revoke.rb PRE-CREATION 
bq.    src/main/ruby/shell/commands/user_permission.rb PRE-CREATION 
bq.  
bq.  Diff: https://reviews.apache.org/r/2041/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Gary
bq.  
bq.


> Coprocessor based simple access control
> ---------------------------------------
>
>                 Key: HBASE-3025
>                 URL: https://issues.apache.org/jira/browse/HBASE-3025
>             Project: HBase
>          Issue Type: Sub-task
>          Components: coprocessors
>            Reporter: Andrew Purtell
>         Attachments: HBASE-3025.1.patch, HBASE-3025.2011-02-01.patch
>
>
> Thanks for the clarification Jeff which reminds me to edit this issue.
> Goals of this issue
> # Client access to HBase is authenticated
> # User data is private unless access has been granted
> # Access to data can be granted at a table or per column family basis. 
> Non-Goals of this issue
> The following items will be left out of the initial implementation for simplicity:
> # Row-level or per value (cell) This would require broader changes for storing the ACLs inline with rows. It's still a future goal, but would slow down the initial implementation considerably.
> # Push down of file ownership to HDFS While table ownership seems like a useful construct to start with (at least to lay the groundwork for future changes), making HBase act as table owners when interacting with HDFS would require more changes. In additional, while HDFS file ownership would make applying quotas easy, and possibly make bulk imports more straightforward, it's not clean it would offer a more secure setup. We'll leave this to evaluate in a later phase.
> # HBase managed "roles" as collections of permissions We will not model "roles" internally in HBase to begin with. We will instead allow group names to be granted permissions, which will allow some external modeling of roles via group memberships. Groups will be created and manipulated externally to HBase. 
> While the assignment of permissions to roles and roles to users (or other roles) allows a great deal of flexibility in security policy, it would add complexity to the initial implementation. 
> After the initial implementation, which will appear on this issue, we will evaluate the addition of role definitions internal to HBase in a new JIRA. In this scheme, administrators could assign permissions specifying HDFS groups, and additionally HBase roles. HBase roles would be created and manipulated internally to HBase, and would appear distinct from HDFS groups via some syntactic sugar. HBase role definitions will be allowed to reference other HBase role definitions. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira