hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6222) Add per-KeyValue Security
Date Tue, 19 Jun 2012 20:44:43 GMT

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

Jonathan Hsieh commented on HBASE-6222:

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

Another thought: At a high level it seems odd for the co-processor to constrain what can be
seen -- we definitely would not want to let a "normal" client view the raw underlaying tags
or visibility metadata tables!

IMO I'd probably prefer a completely generic tag system for HBase only after we have a few
different serious use cases (possibly existing ones!) that would use it.  Making something
overly generic introduces its own set of new problems.

@Keith I'll search on the accumulo mailing to see if things will answer my semantics questions
-- and if I don't find it I'll shoot off some questions there.
> 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
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message