accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: "NOT" operator in visibility string
Date Thu, 20 Mar 2014 15:37:47 GMT
I am curious about your intent when you write "!workspace1", this is
equivalent to every possible authorization except workspace1.  I am
wondering if you actually wanted something more restrictive though, like
the set of all possible workspaces except workspace1?  Do you want to write
something like "b & workspace[2-inf]"?  Where workspace[2-inf] is made up
syntax that means all workspaces with followed by an integer GTE 2.


On Thu, Mar 20, 2014 at 10:36 AM, sfeng88 <susan.feng@altamiracorp.com>wrote:

> I currently work on the same project as Jeff. To elaborate on the Jeff's
> posts, here are some more detailed scenarios of why the NOT operator would
> be helpful.
>
> scenario 1 - hide a value from users "using" workspace1
>
>
> temporarily add "& !workspace1" to data you want to exclude
>
> row1  cf1-col1:value1 []
>         cf1-col2:value2 [a]
> row2 cf1-col1:value3 [b]
>         cf1-col2:value4 [b & !workspace1]
>
> 1) user A scans the table providing authorizations [a,b]
>   --> sees all 4 values
>
> 2) user B scans the table providing authorization [a]
>   --> sees value1, value2
>
> 3) user A when using workspace1 scans the table providing
> authorizations [a,b,workspace1]
>   --> is prevented from seeing value4
>
>
> scenario 2 - hide workspace data from other users
>
>
> add "& workspace2" to private data
>
> row1 cf1-col1:value1 []
>     cf1-col2:value2 [a]
> row2 cf1-col1:value3 [b]
>     cf1-col2:value4 [b & !workspace1]
> row3 cf1-col1:value5 [workspace2]
>     cf1-col2:value6 [a & b & workspace2]
>
> 4) user A scans the table providing authorizations [a,b]
>   --> sees the 4 original values
>
> 5) user B scans the table providing authorization [a]
>   --> sees value1, value2
>
> 6) user A when using workspace2 scans the table providing
> authorizations [a,b,workspace2]
>   --> sees all 6 values
>
>
> scenario 3 - publish workspace data
>
>
> remove "& workspace2" from data no longer required to be private
>
> row1 cf1-col1:value1 []
>     cf1-col2:value2 [a]
> row2 cf1-col1:value3 [b]
>     cf1-col2:value4 [b & !workspace1]
> row3 cf1-col1:value5 [workspace2] --> change to []
>     cf1-col2:value6 [a & b & workspace2] --> change to [a & b]
>
> 7) user A scans the table providing authorizations [a,b]
>   --> sees the 4 original values and newly published value5, value6
>
> 8) user B scans the table providing authorization [a]
>   --> sees value1, value2 and newly published value5
>
>
> scenario 4 - failsecure data
>
>
> no additional data is return when no authorizations are provided
>
> row1 cf1-col1:value1 []
>     cf1-col2:value2 [a]
> row2 cf1-col1:value3 [b]
>     cf1-col2:value4 [b & !workspace1]
> row3 cf1-col1:value5 [workspace2]
>     cf1-col2:value6 [a & b & workspace2]
>
> 9) user A scans the table with no authorizations
>   --> sees only the unmarked value1 (3 fewer than allowed in scenario 2)
>
> 10) user B scans the table with no authorizations
>   -- sees only the unmarked value1 (1 fewer than allowed in scenario 2)
>
>
>
>
> --
> View this message in context:
> http://apache-accumulo.1065345.n5.nabble.com/NOT-operator-in-visibility-string-tp7949p8314.html
> Sent from the Users mailing list archive at Nabble.com.
>

Mime
View raw message