accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 17:12:31 GMT
I feel like that's the space for either refined labelling or the pluggable
authorization framework. Maybe both.

If you have a piece of data that can only be seen under XOR conditions,
then it should probably have a unique label which can be provided under
those conditions from the authorizor.


On Mon, Mar 10, 2014 at 12:40 PM, Keith Turner <keith@deenlo.com> wrote:

> 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