Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - Row level visibility


Copy link to this message
-
Re: Row level visibility
John Vines 2014-01-27, 04:05
It sounds like you want a single owner, multiple consumer setup. I'm
curious why you need to have it set up in a per row basis. Why not let each
data producer have their own table?

Sent from my phone, please pardon the typos and brevity.
On Jan 26, 2014 10:56 PM, "Nehal Mehta" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>> >
>>
>
>