[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150885#comment-13150885 ]
jirapos...@reviews.apache.org commented on HBASE-3025: ------------------------------------------------------ bq. On 2011-11-15 21:01:17, Michael Stack wrote: bq. > security/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java, line 80 bq. > <https://reviews.apache.org/r/2041/diff/3-4/?file=55450#file55450line80> bq. > bq. > You didn't want to change name of table? bq. bq. Gary Helmling wrote: bq. Doesn't seem currently possible to use ".ACL." without changing HTableDescriptor constructors to allow bypassing the isLegalTableName() check? Unless we define a static ACL_TABLEDESC variable in HTD so we can use the protected constructor (same as .META. and -ROOT-). But doing that seems to violate the separation of concerns to me. bq. bq. Michael Stack wrote: bq. " But doing that seems to violate the separation of concerns to me." bq. bq. This is a 'catalog' table? Non-user table? The separation that Gary refers to is between security specific implementation detail and the core code. - Andrew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2041/#review3276 ----------------------------------------------------------- On 2011-11-15 19:54:02, 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-15 19:54:02) 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 4c5e844 bq. src/main/resources/hbase-default.xml 6f98f5d bq. src/main/ruby/hbase.rb 4d27191 bq. src/main/ruby/hbase/admin.rb 17cc891 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 > Priority: Critical > Fix For: 0.92.0 > > 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