[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033061#comment-14033061
]
Andrew Purtell commented on HBASE-10885:
----------------------------------------
{quote}
bq. This isn't quite right though. If there are no tags in the delete cell, but
the cell that is covered by the delete has a visibility expression tag, then we
need to check if the effective auths of the user who issued the delete grant
visibility to the covered cell.
Oh.. Then this becomes more complex. So not only the cell visibility associated
with the delete needs to be considered, in cases that is not present then go
with the Auths defined in the labels table?
{quote}
That's a good point. We may be getting ahead of ourselves here.
Let us separate mechanism and policy considerations.
For mechanism, we have a goal like: IF a delete operation has a visibility
expression associated with it, then the tombstone we lay down should be tagged
with that visibility expression for later evaluation during delete tracking. A
visibility expression defines the auths needed to see the mutation. A delete
mutation is the negation of a put. Therefore, any cells with visibility
expressions that match or are a subset of the expression on the tombstone
should be removed by the delete tracker.
For policy, we have considerations like whether or not to validate if the
visibility expression supplied by a user contains only labels from their
effective auth set.
So why not separate the two for sake of discussion and completing this issue?
If we separate mechanism from policy, then we can complete this issue by
implementing visibility expression based delete tracking but not the other
stuff I started talking about like checking if the effective auths of the user
who issued the delete allow them to use all of the labels in the expression. It
also means that visibility expression based filtering during deletes can be
bypassed by a user just issuing a delete with no expression. However, that's
fine if the goal is providing mechanisms for higher layers to use. It only
becomes a problem if, after finishing this issue, we then debate whether we
should check on all mutations if the labels supplied are in the auth set of the
user....
> 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
> Assignee: ramkrishna.s.vasudevan
> Priority: Blocker
> Fix For: 0.99.0, 0.98.4
>
> Attachments:
> 10885-org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithDeletes-output.txt,
> HBASE-10885_1.patch, HBASE-10885_2.patch, HBASE-10885_new_tag_type_1.patch,
> HBASE-10885_new_tag_type_2.patch, HBASE-10885_v1.patch, HBASE-10885_v2.patch,
> HBASE-10885_v2.patch, HBASE-10885_v2.patch, HBASE-10885_v3.patch,
> HBASE-10885_v4.patch, HBASE-10885_v5.patch
>
>
> 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 of any visibility expression scoping. 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)
