Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 4 Mar 2013 10:37:18 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12560859.1339824610784.374437.1362393438142@arcas>
In-Reply-To: <JIRA.12560859.1339824610784@arcas>
References: <JIRA.12560859.1339824610784@arcas>
Subject: [jira] [Commented] (HBASE-6222) Add per-KeyValue Security
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell commented on HBASE-6222:
---------------------------------------

bq. the choice depends on the number of different ACL are we expecting and if we have access patterns that would make caching efficient. Do we know this?

Maybe for a given row. Wouldn't say so in general but there's no "real world" user usage data. We should expect best practice for a very common cell ACL is a factoring of it to out a CF or table grant, to avoid any IO checking cover for mutations. So at the cell level either no data or probably lots of varying ACLs. 
                
> Add per-KeyValue Security
> -------------------------
>
>                 Key: HBASE-6222
>                 URL: https://issues.apache.org/jira/browse/HBASE-6222
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>    Affects Versions: 0.96.0, 0.98.0
>            Reporter: stack
>            Assignee: Andrew Purtell
>         Attachments: 6222-aclcf.patch, 6222.pdf, cell-acls-kv-tags-not-for-review.zip, HBaseCellRow-LevelSecurityDesignDoc.docx, HBaseCellRow-LevelSecurityPRD.docx
>
>
> 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