[
https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150871#comment-13150871
]
jirapos...@reviews.apache.org commented on HBASE-3025:
------------------------------------------------------
bq. On 2011-11-15 21:01:17, Michael Stack wrote:
bq. > src/main/resources/hbase-default.xml, line 132
bq. > <https://reviews.apache.org/r/2041/diff/3-4/?file=55466#file55466line132>
bq. >
bq. > This looks like its leakage from another issue altogether
bq.
bq. Gary Helmling wrote:
bq. Ugh, no idea where this came from. Thanks for catching, I'll strip it
out.
bq.
bq. Gary Helmling wrote:
bq. Weird, the section highlighted here is not actually in my patch. Just
a trunk change that reviewboard is showing as different from the previous patch
uploaded?
bq.
bq. The actual hbase-default.xml change is:
bq.
bq. + <name>zookeeper.znode.acl.parent</name>
bq. + <value>acl</value>
bq. + <description>Root ZNode for access control lists.</description>
bq. + </property>
bq. +
bq. + <property>
No problem. Long as you commit the right stuff (smile).
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.
" But doing that seems to violate the separation of concerns to me."
This is a 'catalog' table? Non-user table?
- Michael
-----------------------------------------------------------
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
