Yes, dsingley. There's a few reasons not to accept the patch as-is: 1. It completely changes the data security model without offering a way to disable it. For instance, we could have previously assumed that an authorizations service, such as that implemented in ACCUMULO-259 could safely fail with a lockdown mode, by returning an empty set of authorizations for a user. The implication of which would mean that users data could be safely secured in the event of a failure. Introducing a NOT means that this failure mode is not guaranteed to have the intended effect. In general, the design has been that a reduced set of authorizations will result in less access to data, not more.
2. At least as importantly, it's adds no enforceable semantics to the security API. The API permits scanning with a reduced set of authorizations than the max for a user, so a user can still get access to data that it was otherwise not able to with their full authorizations. It may help some use cases, in terms of query convenience, but it does not help secure data in any enforceable way, and that's the whole point of visibility labels in the first place. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Mar 19, 2014 at 4:50 PM, dsingley <[email protected]> wrote: > Assuming Jeff's use case is legitimate and others users can ignore the NOT > feature, is there any other reason not to accept Joe's patch? > > > > -- > View this message in context: > http://apache-accumulo.1065345.n5.nabble.com/NOT-operator-in-visibility-string-tp7949p8288.html > Sent from the Users mailing list archive at Nabble.com.
