On Wed, Mar 19, 2014 at 9:36 AM, kunklejr <[email protected]> wrote:
> So is there any consensus on whether this should be included? I would use > it > right away on a current project if it were. I understand the security risks > that have been discussed with having a NOT operator, but I see its use as a > decision to be made by the development team. If the project deems use of a > the NOT operator as too risky, then they should implement a design that > doesn't use it. I don't think you can prevent people from making poor > decisions/implementations simply by limiting the functionality. It could be > misused as is today. > Could you describe the use case you have in mind? In order for NOT to be usable today, you'd need one of two things: 1) Use of visibility labels for something other than enabling access control (because you'd have to expressly design for users being trusted to only misrepresent themselves appropriately) 2) Client requests would need to pass through an broker application that controlled the set of user authorizations and knew not to leave off any of the ones used in NOT expressions. This would require a hard network boundary between all untrusted clients and Accumulo -Sean
