[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483960#comment-13483960
]
Jerry Chen commented on HBASE-6222:
-----------------------------------
@Jon
bq. From my point of view, I'd like really like to understand more than just
accumulo's implementation – I really care about if accumulo's semantics are 1)
intentional and required for accumulo use cases and 2) if applications only use
a constrained sets of its capabilities. One specific thing I don't quite
understand is the ramifications of having column visibility settings are
encoded as part of the key and sort order. This could be equivalent expressions
that are no longer equals, and some of somewhat goofy future/past views.
I looked into the accumulo implementation. And one thing that accumulo want to
achieve by making the ColumnVisibility as a part of the column key is that the
authorization can be enforced without reading the existing records that may be
affected by the current mutation. Because the ColumnVisibility is part of the
key, you need to explicitly give the ColumnVisibility to identify/match to the
column you are targeting to change (put or delete), and thus
VisibilityConstraint check can be performed on the given ColumnVisibility with
the user's authorization tokens to make sure the user has been authorized for
performing the mutation logically on an existing column, without scanning the
existing columns that it may make changes on. HBase and accumulo are at the
same situation for this.
There may some other issues to be addressed if something is not part of the key
and also not part of the value when multiple versions of a logical column
existed. For example, a Put with new Visibility values of the key of {row1,
family1:qualifier1} will make an logical changes on all the cells with key
{row1, family1:qualifier1}, and thus authorization must be checked over all
these affected items (which may with different Visibility values) with the user
authorization to see whether the Put can be performed or not. And the deletion
gets the same thing to consider when considering DeleteFamily and DeleteColumn
which logically affect a lot of columns that may have different Visibility
values).
One important change on the client API when the Visibility is part of the
column key is the Visibility need to be specified either explicitly or
implicitly (such as empty Visibility is used when no Visibility provided in the
parameters) when performing Put or Delete mutations. This does seem a little
strange at a first glance when comparing with approaches used by traditional
database row level authorization such as Oracle Label Security. But the
question is do we have other better choices both solve the problem and fit into
the current framework?
> Add per-KeyValue Security
> -------------------------
>
> Key: HBASE-6222
> URL: https://issues.apache.org/jira/browse/HBASE-6222
> Project: HBase
> Issue Type: New Feature
> Components: security
> Reporter: stack
>
> Saw an interesting article:
> http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
> "The Senate Armed Services Committee version of the fiscal 2013 national
> defense authorization act (S. 3254) would require DoD agencies to foreswear
> the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO
> certifies that there exists either no viable commercial open source database
> with security features comparable to [Accumulo] (such as the HBase or
> Cassandra databases)..."
> Not sure what a 'commercial open source database' is, and I'm not sure whats
> going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security'
> like Accumulo's, we might put ourselves in the running for federal
> contributions?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
