accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-918) Support secondary ColumnVisibility filtering
Date Tue, 29 Jan 2013 21:13:12 GMT


Hudson commented on ACCUMULO-918:

Integrated in Accumulo-Trunk #688 (See [])
    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/
* /accumulo/trunk/core/src/main/java/org/apache/accumulo/core/iterators/user/

> Support secondary ColumnVisibility filtering
> --------------------------------------------
>                 Key: ACCUMULO-918
>                 URL:
>             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:

View raw message