Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAGHyZ6+-jebtXRm6X9VU_Ei+WkyVhh4T_SKrysKJxhd_m=igkg@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>
Date: Mon, 10 Mar 2014 12:40:19 -0400
Message-ID: 
 <CAGUtCHrcpUyk-bsG_SiR_2tfZpJgLD0pRfz+DXisj0saBiNAkg@mail.gmail.com>
Subject: Re: "NOT" operator in visibility string
From: Keith Turner <keith@deenlo.com>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=bcaec5485ca050039904f44342ee

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

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

--bcaec5485ca050039904f44342ee--