Did there seem to be any performance implications to the patch?
On Wed, Mar 19, 2014 at 5:39 PM, Christopher <[email protected]> wrote: > 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. >
