Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
Reply-To: vines@apache.org
In-Reply-To: 
 <CAGUtCHrcpUyk-bsG_SiR_2tfZpJgLD0pRfz+DXisj0saBiNAkg@mail.gmail.com>
References: <1394052507311-7949.post@n5.nabble.com>
 <CAOyNEs7dj1u+hCGc=sZ-RbmLdid-hTm_weKXCByTrwoNJAy5qA@mail.gmail.com>
 <004301cf3c71$8e2898f0$aa79cad0$@insufficient-light.com>
 <CADczPYTRgVi=3_=7NUv4AkoZ_iA7931YvM_Odfju-ERw6w-dZQ@mail.gmail.com>
 <CAGHyZ6+kNwV7EHjVK=BUk+KLtvW66oJgYu4z=3EQZLqtOMCB3g@mail.gmail.com>
 <CAGUtCHoRW7fEAMrS=eHZA=ZR8+hTmm2Q+rDfed8rU17VTLAevA@mail.gmail.com>
 <CAGHyZ6+-jebtXRm6X9VU_Ei+WkyVhh4T_SKrysKJxhd_m=igkg@mail.gmail.com>
 <CAGUtCHrcpUyk-bsG_SiR_2tfZpJgLD0pRfz+DXisj0saBiNAkg@mail.gmail.com>
From: John Vines <vines@apache.org>
Date: Mon, 10 Mar 2014 13:12:31 -0400
Message-ID: 
 <CADczPYSc3zSui5Z45AdmV7tFQJWXL7qAiMSqSouR-T8VQagW2g@mail.gmail.com>
Subject: Re: "NOT" operator in visibility string
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11c25deadaf2aa04f443b718

--001a11c25deadaf2aa04f443b718
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c25deadaf2aa04f443b718--