What's wrong with the javadoc? The example in the javadoc explicitly says "dog|!cat" is invalid.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Mar 5, 2014 at 8:35 PM, Michael Wall <[email protected]> wrote: > 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 <[email protected]> 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 <[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. > >
