[ 
https://issues.apache.org/jira/browse/HBASE-19842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-19842:
-----------------------------------
    Description: 
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.

  was:
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. 

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.


> 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