[
https://issues.apache.org/jira/browse/ACCUMULO-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566958#comment-13566958
]
Hudson commented on ACCUMULO-918:
---------------------------------
Integrated in Accumulo-Trunk-Hadoop-2.0 #49 (See
[https://builds.apache.org/job/Accumulo-Trunk-Hadoop-2.0/49/])
ACCUMULO-918 Added unit tests and fixed a few discovered bugs in user
visibility filter (specifically, made the invalid label check use the cache,
and fixed
empty authorizations problem). (Revision 1440627)
Result = SUCCESS
ctubbsii :
Files :
*
/accumulo/trunk/core/src/main/java/org/apache/accumulo/core/iterators/user/VisibilityFilter.java
*
/accumulo/trunk/core/src/test/java/org/apache/accumulo/core/iterators/user/VisibilityFilterTest.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
