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, get federal funding for HBase?
Date Sat, 16 Jun 2012 21:12:42 GMT

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

Jonathan Hsieh commented on HBASE-6222:
---------------------------------------

Do we think of the goal of faithfully mimicking accumulo's is reasonable?  (my first impression
is yes). If so, I think we'd need to define those semantics and to do that we'd need bring
up an accumulo cluster (or spend more time in the code) to see what its semantics are.  

Here's the accumulo api.  (ColumnVisibility is tag expression)
http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/data/Mutation.html

You can see that delete mutations in accumulo also have visibility expressions -- and I'm
not actually sure what the semantics are.  Let's say you have a "public" put on row A, and
then a "sensitive" delete of the entire row A.  Does someone with the only the "public" authorizations
see the old row A, or no row A?  If it was no row A, would they be able to do a versioned
query and get the old row A (and could then infer out that there was a sensitive delete?)...

Also, I didn't see atomic increment operator in accumulo.  If it doesn't exist we'd have to
define that behavior. Some options:
1) No visibility settings on hbase increment mutation operations, thus only keep only one
value always readable by all
2) Add some mechanism to set counter visibility so we could to require authorization to read.

3) Keep one counter for each visibility tag on a particular cell... (yuck).
                
> Add per-KeyValue Security, get federal funding for HBase?
> ---------------------------------------------------------
>
>                 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message