[ https://issues.apache.org/jira/browse/HBASE-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153068#comment-13153068 ]
stack commented on HBASE-3025: ------------------------------ hadoopqa is failing some tests because of 'too many open files' Its failing distributedlogsplitting for same reason. I'd say its not your patch. > 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_5.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