accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 16:34:43 GMT


On 3/10/14, 12:19 PM, Sean Busbey 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
> <mailto:keith@deenlo.com>> wrote:
>
>
>
>
>     On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey
>     <busbey+lists@cloudera.com <mailto: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)
>
> 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.

A quick glance: it doesn't really look like they considered this (or a 
few other things we specifically avoided), but I haven't thoroughly read 
everything (there was a lot of discussion).

One of the design docs[1] referenced making "a super-user visibility 
that can see all other visibilities".

Dropping authorizations that the user doesn't have is also a divergence, 
where we fail loudly (Exception) at them. [2]

[1] 
https://issues.apache.org/jira/secure/attachment/12552508/HBaseCellRow-LevelSecurityPRD.docx
[2] 
https://communities.intel.com/community/itpeernetwork/datastack/blog/2013/10/29/hbase-cell-security

Mime
View raw message