hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-10885) Support visibility expressions on Deletes
Date Thu, 03 Apr 2014 09:01:38 GMT

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

Andrew Purtell edited comment on HBASE-10885 at 4/3/14 9:00 AM:
----------------------------------------------------------------

bq. Doing like what ACL does may be easier because we could see which subject issues the delete.
If a super user/admin that makes the put does the delete then we can just allow the delete
to happen.

Above I suggest splitting the authorization check and the actual delete handling. Do the authorization
check in the preDelete hook because we have the user's effective label set in the RPC context.
Do the delete handling in compaction because for the deleteColumn or deleteFamily cases if
we convert that delete request to a set of per-cell deletes, this could produce an explosion
of tombstones. 

bq. Apart from this with the ACL delete handling case, some doubts regarding the handling
of the deleteColumn() -  which deletes only the latest version.  But with the current implementation
even though the current version allows the delete with valid permissions for the user, because
there is an older version with lesser permission we deny the delete.  Is that valid? same
applies with deleteFamily() also.

Yes, the rule is all visible cells with an ACL must allow the delete, or the delete will be
denied. However, we should respect the MAX_VERSIONS of column families as defined in the schema
when determining the scope of visibility and so changes are needed for that (HBASE-10899).



was (Author: apurtell):
bq. Doing like what ACL does may be easier because we could see which subject issues the delete.
If a super user/admin that makes the put does the delete then we can just allow the delete
to happen.

Above I suggest splitting the authorization check and the actual delete handling. Do the authorization
check in the preDelete hook because we have the user's effective label set in the RPC context.
Do the delete handling in compaction because for the deleteColumn or deleteFamily cases if
we convert that delete request to a set of per-cell deletes, this could produce an explosion
of tombstones. 

bq. Apart from this with the ACL delete handling case, some doubts regarding the handling
of the deleteColumn() -  which deletes only the latest version.  But with the current implementation
even though the current version allows the delete with valid permissions for the user, because
there is an older version with lesser permission we deny the delete.  Is that valid? same
applies with deleteFamily() also.

Yes, the rule is all visible cells with an ACL must allow the delete, or the delete will be
denied. However, we should respect the MAX_VERSION of the schema when determining the scope
of visibility and so changes are needed for that (HBASE-10899). 

> 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
>             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 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)

Mime
View raw message