accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: "NOT" operator in visibility string
Date Thu, 20 Mar 2014 14:52:32 GMT
For scenarios 1-3, that's not a scalable approach. Every time one of 
these operations occurs, you're re-creating *double* the size of the 
original dataset (your "workspace") by deleting and then re-inserting 
every key-value.

I believe this has already been said, but this is the job of an 
authorization service, and cell-level visibilities do not appropriately 
solve this problem.

On 3/20/14, 10:36 AM, sfeng88 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