[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956211#comment-13956211
]
Andrew Purtell commented on HBASE-10885:
----------------------------------------
How we handle deletes in the AccessController is to only allow the delete if it
has covering permission. By that I mean CF ACLs and any ACLs in cells that
would be covered by the tombstone not already covered by a tombstone must grant
the subject access. If any do not, the delete is denied. We run an internal
RegionScanner to enumerate the cells that would be affected by the operation.
One way to do this for the VisibilityController is we could similarly run an
internal RegionScanner with the parameters of the submitted Delete op, filter
cells by effective visibility, and issue deletes scoped only to those cells
visible to the subject. This would be easier than trying to hook compaction
scanners and evaluating visibility expression tags there, because we will have
the effective label set for the user in the RPC context, not at compaction
time.
> Support visibility expressions on Deletes
> -----------------------------------------
>
> Key: HBASE-10885
> URL: https://issues.apache.org/jira/browse/HBASE-10885
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.98.1
> Reporter: Andrew Purtell
> Fix For: 0.99.0, 0.98.2
>
>
> Accumulo can specify visibility expressions for delete markers. During
> compaction the cells covered by the tombstone are determined in part by
> matching the visibility expression. This is useful for the use case of data
> set coalescing, where entries from multiple data sets carrying different
> labels are combined into one common large table. Later, a subset of entries
> can be conveniently removed using visibility expressions.
> Currently doing the same in HBase would only be possible with a custom
> coprocessor. Otherwise, a Delete will affect all cells covered by the
> tombstone regardless if they are visible to the user issuing the delete or
> not. This is correct behavior in that no data spill is possible, but
> certainly could be surprising, and is only meant to be transitional. We
> decided not to support visibility expressions on Deletes to control the
> complexity of the initial implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
