accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 16:19:40 GMT

We may be getting into the weeds enough to remove user@accumulo, but I'll
leave in place for now.

inline below

On Mon, Mar 10, 2014 at 11:10 AM, Keith Turner <> wrote:

> On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey <>wrote:
>> Phil,
>> What John is getting at here is that since Accumulo's security label
>> model is trying to enforce role presence, our APIs allow a user to request
>> that only a subset of their authorizations be used in a given request.
>> The ability to request only a subset of authorizations on a per-request
>> basis is needed to implement some common Accumulo use cases (such as a
>> trusted application filtering for a variety of users in an multi-level
>> security environment).
> To safely add not, it seems like we would also need to add the concept of
> a minimal authorization set.  Currently an Accumulo user has a maximum set
> of authorizations they can query.  However they can choose to use any
> subset of this including the empty set.  For exmaple Accumulo user doc has
> a maximum authorization set of (doctor, researcher) and a minimal set
> (doctor).  So every scan must specify at least 'doctor' or it will fail.
> This seems very complicated and easy for users to get wrong.

I agree that this is adding a significant amount of complexity. One option
would be to annotate NOT as advisory, or to specify in the docs that it'd
be up to the application layer to enforce the inclusion of the minimal set.
(then again, that leaves even more room for erroneous implementations)

Does anyone have time to review the design docs from HBase's implementation
of cell level visibilities? I know their visibility parsing allows NOT and
I'm wondering if they worked through this already.

View raw message