Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 29 Oct 2012 02:15:15 +0000 (UTC)
From: "Jerry Chen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1627829593.37687.1351476915213.JavaMail.jiratomcat@arcas>
In-Reply-To: <1104092684.21359.1339824642708.JavaMail.jiratomcat@issues-vm>
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=13485788#comment-13485788 ] 

Jerry Chen commented on HBASE-6222:
-----------------------------------

[~saint.ack@gmail.com]
bq. A put that broadened visibility would be for the current put only? How would it effect already-put values?
When the visibility is part of the column key, a broadened visibility will not affect the existing columns that with the same {rowid, family, qualifier} but with different visibilities. Thus, the put will only affect the columns that has the same {rowid, family, qualifier, visibility}. Different visibilities has the same effect as different qualifiers.

While as to DeleteFamily or DeleteColumn, Accumulo doesn't have such as operations. It has only Delete mutation to delete a specified {rowid, family, qualifier, visibility}. The idea to keep DeleteFamily and DeleteColumn still working with visibility in HBase is that A DeleteFamily operation now will only affect "all columns in this family with the specified visibility" other than originally "all columns in this family". The same with DeleteColumn.

One thing to consider if the visibility is part of the key. As there are suggestions to provide support for general tags for KV so that not only visibility tags can be stored in it, but also other tags that needed in the future can be added easily. Will general tags concept (comparing to a visibility tag) makes the concept of the column key too complex?


> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira