accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wall <mjw...@gmail.com>
Subject Re: "NOT" operator in visibility string
Date Thu, 06 Mar 2014 01:35:55 GMT
Perhaps the javadoc should be updated?

http://accumulo.apache.org/1.5/apidocs/org/apache/accumulo/core/security/ColumnVisibility.html#ColumnVisibility(java.lang.String)

Mike


On Wed, Mar 5, 2014 at 8:16 PM, Christopher <ctubbsii@apache.org> wrote:

> This has been discussed for inclusion in the past. The reason it has
> not been implemented is that new users with no authorizations yet, a
> typo in a user's authorizations, or a hiccup in the authorization
> retrieval system, a minor misconfiguration, or some other thing, could
> expose data inadvertently. There are risks of this happening anyway
> (mislabeling data, or assigning incorrect authorizations), but this
> adds another dimension to those risks, and it's actually much worse
> than that.
>
> Accumulo's visibility labels implement role-based mandatory access
> controls. Allowing a NOT operator would mean that you have to have
> *complete* knowledge of your data in order to apply the correct
> visibility labels in order to restrict access to that data to
> authorized users. Not only would you have to know what a user is
> explicitly allowed to see, by role/category or whatever you use
> authorizations labels to represent, but you also have to know *EVERY*
> piece of data with a NOT in its label in order to apply it to users in
> order to restrict their access. (Example: you'd have to know to apply
> "B" to all restricted users if there's any possibility of data
> entering the system labeled as "A|!B"). As such, NOT runs contrary to
> Accumulo's data protection design principle of "default restricted".
>
> Without NOT, Accumulo's visibility labeling system is not functionally
> complete, but it does satisfy the requirements for strict control over
> data access. However, I empathize with the desire to include such a
> feature, as there are certain use cases which simply cannot be
> implemented easily without a functional-completeness. As such, I would
> personally support your efforts to include a patch to implement it, so
> long as it was not enabled by default. If you really need this
> feature, I'd suggest doing the work to make the visibility evaluation
> pieces pluggable, with a "default restricted" one as the provided and
> default implementation.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Mar 5, 2014 at 3:48 PM, joeferner <joe.m.ferner@gmail.com> wrote:
> > I'm looking at implementing the "NOT" operator in visibility strings. I
> > actually have it working just need to write some unit tests for it. I was
> > wondering if there was any reason why it don't exist now? It looks to be
> > explicitly called out in the docs "dog|!cat".
> >
> > The new HBase also looks to support the "NOT" operator:
> > https://hbase.apache.org/book/hbase.visibility.labels.html
> >
> >
> >
> > --
> > View this message in context:
> http://apache-accumulo.1065345.n5.nabble.com/NOT-operator-in-visibility-string-tp7949.html
> > Sent from the Users mailing list archive at Nabble.com.
>

Mime
View raw message