accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Kunkle <kunkl...@gmail.com>
Subject Re: "NOT" operator in visibility string
Date Wed, 19 Mar 2014 16:54:02 GMT
Hi John,

Yes it’s accurate that the system controls the label and who is associated with it; there
are no Accumulo-internal user accounts. But I don’t think it’s feasible to remove a sandbox
label from something that should be hidden. Such a scenario would imply that all data is “tagged”
with the labels of every sandbox that is allowed to see the data, which would be most. It
would also imply that the creation of a new sandbox would necessitate changing the visibility
of everything in Accumulo to include the new sandbox label, effectively rewriting the entire
database. Sanboxes are created and deleted all the time in our application, so it doesn’t
seem like a feasible solution to me.

-Jeff

On Mar 19, 2014, at 12:16 PM, Josh Elser <josh.elser@gmail.com> wrote:

> It kind of sounds like you could manage this much easier by controlling the authorizations
a user gets (notably the workspace name) and the grant/revoke above the Accumulo level.
> 
> A sandbox has a unique label and the external system controls which users are granted
that label. This way, each sandbox can be modified individually (using authorizations that
contain the data visibility and the sandbox label) or the original data set could be modified
(by omitting a sandbox label in the authorizations used).
> 
> Is that accurate?
> 
> On 3/19/14, 12:05 PM, Jeff Kunkle wrote:
>> I attempted to simplify the scenario to facilitate discussion, which on
>> second thought may have been a mistake. Here’s the whole scenario:
>> 
>> Different users have access to different subsets of the data depending
>> on their authorizations and the visibility of the data. Users “work
>> with” the data in what we call a sandbox. Sanboxes can be shared with
>> other users (this is the group creation I was talking about earlier).
>> Deletes to the data would be “scoped” to the sandbox by changing the
>> visibility to add “& !workspace_name” so that people viewing the
>> workspace wouldn’t see the data but everyone else would.
>> 
>> On Mar 19, 2014, at 11:48 AM, Sean Busbey <busbey+lists@cloudera.com
>> <mailto:busbey+lists@cloudera.com>> wrote:
>> 
>>> On Wed, Mar 19, 2014 at 10:43 AM, Jeff Kunkle <kunklejr@gmail.com
>>> <mailto:kunklejr@gmail.com>> wrote:
>>> 
>>>    New groups are created on the fly by our application when needed.
>>>    Under the scenario you describe we’d have to go through all the
>>>    data in Accumulo whenever a group is created so that users in the
>>>    group can see the existing data.
>>> 
>>> 
>>> 
>>> 
>>> Ah! So your use case is that all data defaults to world readable and
>>> then users have the option of opting out of seeing subsets. Right?
>>> 
>>> In your scenario user groups also get to opt-out of seeing data on the
>>> fly, yes? Both require rewriting the data. Does the group creation
>>> happen more often?
>> 


Mime
View raw message