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.
