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 <[email protected]> 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.
