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
Bob.Thorman@... 2014-01-27, 14:51
Nehal

Having done this very same thing, you're going to have to abstract the two user groups through two client connections to accumulo.  One client connection will have limited read/access table rights, while the other has read/write.  Then the visibilities of the user groups will have to be managed through a mapping of their personal credential to a set of accumulo visibilities.  With these two authorization steps you can accomplish what you're after.

-----Original Message-----
From: Nehal Mehta [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 26, 2014 10:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Row level visibility

Thanks for all information.

But VisibilityConstraint disallows user writing data that it cannot see.
Correct me if I am wrong.

In our use case as mentioned above, we want one set of user who can still read/access that data but not update it. So each cell we need to store read as well as write visibility. We cannot have one single environment based constraint.  Do you people know if anyone else in community requires such visibility granularity?

Thanks,
Nehal
On Sun, Jan 26, 2014 at 11:29 PM, Josh Elser <[EMAIL PROTECTED]> wrote:

> 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 <[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
>>>