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 <ctubb...@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.fer...@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. >
