accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 16:40:19 GMT
On Mon, Mar 10, 2014 at 12:19 PM, Sean Busbey <busbey+lists@cloudera.com>wrote:

> +dev@accumulo
>
> 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 <keith@deenlo.com> wrote:
>
> >
> >
> >
> > On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey <busbey+lists@cloudera.com
> >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)
>

If we are going to do it, I think we should try to come up with a design
that solves end-to-end use cases. The not op seems useful but also
dangerous, there is a real possibility of unintended data leakage.  A
minimal authorization set is a solution.  Are there other solutions? Ones
that better translate a users intent into constraints in the system.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message