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