If you have full control of access to Accumulo, then it's just as easy to remove that visibility from the incoming set.
On Wed, Mar 19, 2014 at 11:22 AM, Jeff Kunkle <[email protected]> wrote: > 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 > > >
