accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: "NOT" operator in visibility string
Date Wed, 19 Mar 2014 15:48:30 GMT
What you are describing is "dotfile behavior": that is, ignoring files
that begin with '.' from a directory listing, by default, but not
actually protecting them from being visible if a user really wants
them to be. It seems odd to me that this use case should be attempted
to be satisfied by altering the visibility label, in much the same way
that it would seem odd to me to incorporate this in file system
permissions for dotfiles.

However, here's some better approaches, which achieve the same thing,
but don't require NOT (and its implications). These use iterators,
because filtering is what iterators are good at:

1) Without touching visibility labels, create an "optional" column
family, and apply a filter iterator to suppress it. (Variations:
encode the "optional" flag elsewhere in the row/col/value and filter
on that).

2) Create visibility labels that look like (A|(A&OPTIONAL)), where A
is your mandatory access controls and OPTIONAL is a flag which does
not affect the visibility, but allows you to filter, with an iterator.

Christopher L Tubbs II

On Wed, Mar 19, 2014 at 11:22 AM, Jeff Kunkle <> 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 <> wrote:
> On Wed, Mar 19, 2014 at 9:36 AM, kunklejr <> 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

View raw message