hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6222) Add per-KeyValue Security
Date Sun, 17 Jun 2012 05:22:43 GMT

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

stack commented on HBASE-6222:
------------------------------

@Lars When you say "...I thought it might be good to have the option to add "tags" to each
KV", what would a tag look like?  A bit set?  Or some name/values within the KV?

I like Jon's suggestion that HBASE-2893 could be less onerous if we implemented Locality groups
(the meta-cf would be co-mingled w/ the data its meta for).

bq. They delta encode their keys (including the visiblity tags) like we do in 0.94.

Should we turn the above on as default?

bq. As a straw man, a core-changing HBase version that modified KV's wouldn't necessarily
incur more space – we could use a new KeyValue.Type (TaggedPut?) that had visibility settings,
and use the old Put type that used the default tags.

KVs are also versioned so we should be able to up the version and add new in-key facility
(A while back I messed w/ doing this adding a sequenceid beside the timestamp... I did it
as "conditional code" rather than as subclass which for sure compounded the complexity of
the already-complex KeyValue -- unfortunately, hopefully there is a better route -- but it
seemed possible making different KV types float in same scanner merge....).  If we add a ColumnVisibility-like
expression into the KV, we'd have to update Comparators to exclude this portion from inclusion
in sort.

On making KV an Interface, that'd be cool.  Todd had a go at it a while back but the ripple
turned into an avalanche of code changes IIRC so he suggested we do it piecemeal.  It'd be
sweet though.

+1 on Andrew's proposal first.  We need a driver?

On faithful mimicking of Accumulo's implementation, that makes sense in the absence of an
actual customer who needs this stuff (Jon? You have one?)?  Maybe the Accumulo implementation
is far from what is wanted -- these 'expression's are passed in the clear -- and a superior
implementation might not be that much of a stretch? 
                
> 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: 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