[
https://issues.apache.org/jira/browse/HBASE-7663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813021#comment-13813021
]
Andrew Purtell commented on HBASE-7663:
---------------------------------------
Carrying over a discussion from RB:
{quote}
If the latest KV was skipped due to a label mismatch the previous KV was
getting included. May be we can check for the same in ACLs too? we can come up
with a common soln.
{quote}
This is correct behavior. Cell permissions are a part of the HBase data model,
not separate from it. If you want to hide/overwrite all previous versions of a
cell then you have to lay down a delete marker and then a new value with a
later timestamp. If you want only one version of a cell with the latest
visibility or ACL, then it's the same. This is easy to reason about.
We say all policies apply at the point in time when the value is stored. This
allows easy policy evolution over time. If a user does not have permission or
visibility to read the current value, but did have permission or visibility to
read the previous version, then they should still see the previous version,
because the policy that allowed the user to read the previous version was in
effect at that time.
This does make increments and appends interesting but otherwise we are special
casing how permissions work relative the rest of the HBase model. We should
document this stuff carefully.
If delete-then-put (or read-delete-put) is inconvenient (I think it is
explicit) then we can consider adding a DeleteAndPut op or similar. Actually
that would also address open JIRAs regarding deletes and puts with the same
timestamp.
> [Per-KV security] Visibility labels
> -----------------------------------
>
> Key: HBASE-7663
> URL: https://issues.apache.org/jira/browse/HBASE-7663
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
> Affects Versions: 0.98.0
> Reporter: Andrew Purtell
> Assignee: Anoop Sam John
> Fix For: 0.98.0
>
> Attachments: HBASE-7663.patch, HBASE-7663_V2.patch,
> HBASE-7663_V3.patch, HBASE-7663_V4.patch, HBASE-7663_V5.patch
>
>
> Implement Accumulo-style visibility labels. Consider the following design
> principles:
> - Coprocessor based implementation
> - Minimal to no changes to core code
> - Use KeyValue tags (HBASE-7448) to carry labels
> - Use OperationWithAttributes# {get,set}Attribute for handling visibility
> labels in the API
> - Implement a new filter for evaluating visibility labels as KVs are streamed
> through.
> This approach would be consistent in deployment and API details with other
> per-KV security work, supporting environments where they might be both be
> employed, even stacked on some tables.
> See the parent issue for more discussion.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
