Details
Major Description
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: a,b
User can see entries labeled with any of the following:
a
a|b
If the user desired to only view entries that matched the disjunction, a|b, and not a 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 a AND visible by b.
After the system iterator is applied, the user can see:
a
a|b
After the second iterator is applied, with the authorizations b specified, the user can see only:
a|b
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.
