[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494519#comment-13494519
]
Himanshu Vashishtha commented on HBASE-6222:
--------------------------------------------
[~apurtell]Thanks for the writeup. Yes, your approach is different. Few
thoughts:
a) Its not clear how/where you are storing the acls at keyvalue level. You use
_acl_ table, or something else? Reading through this gives an idea that the
keyvalue level acls have null table, cf and cq attribute with them. Does this
mean a user can have only one type of KV level acls in the application. Or in
other words, how does the KV acl looks like in the _acl_ table?
b) Currently, all the acl entries are stored in zk (limit of znode is 1 mb);
will you be using the same approach?
bq. It doesn't make sense to attach an ACL on a Delete, because the KVs covered
by the delete will be ... deleted.
I don't completely agree with this but will not comment also unless I
completely understand your approach.
[[email protected]] Thanks for taking time to read through it.
bq. Versions will be kept for each unique visibility expression.Would this
inflate memstore because we are keeping potentially many more versions of
KeyValue which differ by visibility expression only ?
Or HFile, right? If so, yes, as different visibility expressions provides
different access control to user. If user A does two Put with Visibility A|B, C
and then does a delete with visibility A|B, another user with acl of C should
be able to see this.
re: ENABLE_CELL_LEVEL_SECURITY
I initially visualized a table level (will give some more thought about CF
level... as mentioned in the doc also)
Yes, change it after disabling the table as it will flush out the memstore.
re: Multiple CVFilter
No, only one should be good enough. How come you got this idea? I should fix
the doc.
re: Typo:
Yes, he will get v2 and v4. Thanks for pointing this out.
> 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
> Assignee: Andrew Purtell
> Attachments: 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
