Row level visibility

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Row level visibility

Nehal Mehta
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
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

John Vines-3
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

Nehal Mehta
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 <[hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

John Vines-3
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

Nehal Mehta
We have ported graph database Titan <http://titan.thinkaurelius.com/> to
use accumulo as storage engine. In graph, suppose we have N number of
nodes. We want one set of users to create edges connecting those nodes. We
want other users to add more edges using already created edges/nodes to
same group. but not able to update those edges as they may not have
permission to those.

Our graph would end up having billions of edges, so can't have them their
own tables as retrieving from those tables would be even complex.  So yes
"One set of owner, larger set of consumer" set up is required to have that.

Thanks,
Nehal




On Sun, Jan 26, 2014 at 11:05 PM, John Vines <[hidden email]> wrote:

> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> >
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

John Vines-3
Constraints are a pluggable system as well, so there still may be options
through those to provide the level of interaction that you require.


On Sun, Jan 26, 2014 at 11:26 PM, Nehal Mehta <[hidden email]> wrote:

> We have ported graph database Titan <http://titan.thinkaurelius.com/> to
> use accumulo as storage engine. In graph, suppose we have N number of
> nodes. We want one set of users to create edges connecting those nodes. We
> want other users to add more edges using already created edges/nodes to
> same group. but not able to update those edges as they may not have
> permission to those.
>
> Our graph would end up having billions of edges, so can't have them their
> own tables as retrieving from those tables would be even complex.  So yes
> "One set of owner, larger set of consumer" set up is required to have that.
>
> Thanks,
> Nehal
>
>
>
>
> On Sun, Jan 26, 2014 at 11:05 PM, John Vines <[hidden email]> wrote:
>
>> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>> >
>>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

Josh Elser
In reply to this post by Nehal Mehta
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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

Nehal Mehta
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

RE: Row level visibility

thormanrd
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:[hidden email]]
Sent: Sunday, January 26, 2014 10:45 PM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Row level visibility

ashutosh.srivastava
In reply to this post by Nehal Mehta
You can use the table permissions to solve your purpose, For example you could give the same visibility to both the read as well as the update user so that they can view the data. Give Table.READ permission to the read user, and Table.READ as well as Table.WRITE permission to the update user this will make him read as well as write to the table