Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 29 Jan 2013 21:13:12 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12624732.1355959724803.211204.1359493992926@arcas>
In-Reply-To: <JIRA.12624732.1355959724803@arcas>
References: <JIRA.12624732.1355959724803@arcas>
Subject: [jira] [Commented] (ACCUMULO-918) Support secondary
 ColumnVisibility filtering
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hudson commented on ACCUMULO-918:
---------------------------------

Integrated in Accumulo-Trunk #688 (See [https://builds.apache.org/job/Accumulo-Trunk/688/])
    ACCUMULO-918 Added user iterator for visibilities. TODO: add a test. (Revision 1440118)

     Result = SUCCESS
ctubbsii : 
Files : 
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/iterators/system/VisibilityFilter.java
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/iterators/user/VisibilityFilter.java

                
> Support secondary ColumnVisibility filtering
> --------------------------------------------
>
>                 Key: ACCUMULO-918
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-918
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>              Labels: filter, iterator, label, visibility
>             Fix For: 1.5.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> To some degree, users have the ability to choose what to see during a scan, by providing a subset of their own authorizations at scan time. However, even this only gives the user the ability to filter using a *disjunction* of all elements in that subset (in other words, if it matches *any* of their authorizations). Users are not able to request data that matches a *conjunction* of the elements in their set of authorizations (or the subset requested at scan time).
> Example:
> User has auths: {color:blue}a,b{color}
> User can see entries labeled with any of the following:
> {color:blue}
> {noformat}
> a
> a|b
> {noformat}
> {color}
> If the user desired to only view entries that matched the disjunction, {color:blue}a|b{color}, and not {color}a{color} only, then this is not currently possible. The reason this isn't possible is because the design of the VisibilityFilter is to prevent users from getting access to data they are not allowed to see. It does nothing to constrain the data to only what they *want* to see.
> This can be done on the client side, but it can also be achieved with a secondary filter applied later in the iterator stack, so that the undesirable data doesn't get sent back over the network in the first place.
> Consider the same situation, but the user wants to match entries that are visible by {color:blue}a{color} *AND* visible by {color:blue}b{color}.
> After the system iterator is applied, the user can see:
> {color:blue}
> {noformat}
> a
> a|b
> {noformat}
> {color}
> After the second iterator is applied, with the authorizations {color:blue}b{color} specified, the user can see only:
> {color:blue}
> {noformat}
> a|b
> {noformat}
> {color}
> As a system iterator, the current VisibilityFilter cannot be used by users, as it doesn't properly get initialized with init(), and is constructed using an alternate constructor on the tserver. So, the VisibilityFilter needs to be changed to support being used by users in the iterator stack, or another filter needs to provide similar functionality for users.

--
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