[
https://issues.apache.org/jira/browse/HBASE-19842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva reassigned HBASE-19842:
--
Assignee: (was: Thomas D'Silva)
> 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
>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)
