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

Andrew Purtell commented on HBASE-19842:
----------------------------------------

Improved the description a bit.

> Cell ACLs v2
> ------------
>
>                 Key: HBASE-19842
>                 URL: https://issues.apache.org/jira/browse/HBASE-19842
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>            Reporter: Andrew Purtell
>            Assignee: Thomas D'Silva
>            Priority: Major
>
> Per cell ACLs as currently implemented (HBASE-7662) embed the serialized ACL 
> in a tag stored with each cell. This was done for performance. This has some 
> drawbacks, most significantly unnecessary duplication and to grant or revoke 
> requires a rewrite of every affected cell. We could implement them in a space 
> efficient (and management efficient) way at the cost of some performance like 
> so:
> First, allow storage of cell level ACLs in the ACL table. Rowkey would be a 
> generic identifier of some kind that can be distinguished from existing 
> rowkeys that associate the ACL with a cf, or table, or namespace. Existing 
> code for cf/table/namespace ACLs should ignore rows that do not conform to 
> today's keying strategy. 
> Then provide the option for storing the rowkey of an entry in the ACL table 
> in the cell ACL tag instead of the complete serialization. Allocate a new 
> cell tag ID to distinguish v2 ACL references from v1 embedded ACL 
> serializations.
> The advantages would be reduction of unnecessary duplication, and, like ACLs 
> at other granularities, a GRANT or REVOKE which updates the ACL table will 
> update access control rules for all affected cells. The disadvantage would be 
> in order to process the reference to the ACL for each cell with an ACL 
> reference in a tag we will need to look up the ACL in the ACL table.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to