[
https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140890#comment-13140890
]
jirapos...@reviews.apache.org commented on HBASE-3025:
------------------------------------------------------
bq. On 2011-09-27 16:58:47, Andrew Purtell wrote:
bq. >
security/src/main/java/org/apache/hadoop/hbase/security/rbac/AccessController.java,
line 192
bq. > <https://reviews.apache.org/r/2041/diff/1/?file=45404#file45404line192>
bq. >
bq. > Debug logging should go to LOG not AUDITLOG
bq.
bq. Gary Helmling wrote:
bq. The idea was that all authorization decisions should be separated into
audit log. Here we're allowing access, so AUDITLOG seemed to make sense. I
agree that this still needs to be cleaned up a lot. Maybe all audit logging
should be done up in requirePermission() with authorization result? At the
very least we need a consistent format and consistent logging levels for
messages (trace, right?).
bq.
bq. Andrew Purtell wrote:
bq. > Maybe all audit logging should be done up in requirePermission()
with authorization result?
bq.
bq. Sounds good.
bq.
bq. > At the very least we need a consistent format and consistent logging
levels for messages (trace, right?).
bq.
bq. I'd argue for TRACE
bq.
bq. Gary Helmling wrote:
bq. Reworked the audit logging to happen in requirePermission(), so we get
a single log message per auth check indicating success or failure, with a more
consistent format. Result is logged to AUDITLOG at trace level.
Is there TRACE level in our commons interface? I believe it just maps to DEBUG?
- Michael
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2041/#review2077
-----------------------------------------------------------
On 2011-11-01 00:26:37, 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 00:26:37)
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
