accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Row level visibility
Date Mon, 27 Jan 2014 04:29:04 GMT
It sounds like you might be able to use something like the Constraint[1] 
interface, notably the VisibilityConstraint[2] implementation, to get 
what you want already.

That would disallow any updates with a visibility that the user writing 
the data cannot see. You could probably come up with a way to structure 
your visibilities to work within that functionality.

[1] 
http://accumulo.apache.org/1.5/apidocs/org/apache/accumulo/core/constraints/Constraint.html
[2] 
http://accumulo.apache.org/1.5/apidocs/org/apache/accumulo/core/security/VisibilityConstraint.html

On 1/26/14, 10:55 PM, Nehal Mehta wrote:
> Thanks John. I do understand we can define those permissions at table level
> or user level. Our application needs it to be defined at row/cell level.
>
> But here what we are trying to achieve is to have them at row level. So
> suppose a user of group inserts data, it can be updated by same group but
> not another group. Multiple other groups can still read that data.  So
> basically we would have to define it at row level. In that way, lot of
> applications can be developed on top of accumulo without worrying about
> read-update validations at application.
>
> Basically we want row level information to be created and updated by one
> set of group but can be read by multiple groups. Multiple groups write data
> to that same table. Do you think accumulo wants to support that in future?
> Instead of having just cell visibility we have two set of visibility for
> each cell: 1) Read Visibility 2) Write (Update) Visibility.
>
> Thanks,
> Nehal
>
>
>
>
> On Sun, Jan 26, 2014 at 9:59 PM, John Vines <vines@apache.org> wrote:
>
>> I think there may be two things which would satisfy your request.
>>
>> 1. For tables, there are both READ and WRITE ACLs used to determine read
>> and write access. If a user does not have read permission, they will be
>> unable to get any data (with READ permissions, it will then fall back to
>> the authorizations). Similarly, if a user lacks the WRITE permission, they
>> can't do any inserts.
>>
>> 2. For a user with WRITE permission, there is a constraint which can be
>> applied to a table which only allows them to write data with a label they
>> have permission to read. This would effectively allow cell level write
>> control, in addition to read control.
>>
>> Hopefully that provides some insight.
>>
>>
>> On Sun, Jan 26, 2014 at 7:51 PM, Nehal Mehta <nehal413@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Is accumulo considering row level visibility for read and write
>> (updates).
>>> Basically in one of our application we want user to insert rows with
>>> different visibility options for updating that row vs reading that row.
>> We
>>> want one role to be restricted to just read that row but another special
>>> role to update as well as read that row.
>>>
>>> By having read and update visibility accumulo can expose more rows as
>> there
>>> is no fear of them being updated.
>>>
>>> I am relatively new user of accumulo and if this is already discussed in
>>> past, can anyone guide me to that discussion?
>>>
>>> Thanks,
>>> Nehal
>>>
>>
>

Mime
View raw message