My particular use case meets both of those conditions. I’d like to use a not operator to soft delete things for specific groups of users, which are assigned a given authorization. For example, assume I have two groups of users: group1 and group2. If I want to temporarily hide something from group1 I would add “& !group1” to the visibility. In my case I’m not really using the NOT operator for access control. The users in the group have access to the data; they’ve just chosen to hide it from their view. On Mar 19, 2014, at 10:47 AM, Sean Busbey <[email protected]> wrote:
> > 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
