accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 15:50:49 GMT

What John is getting at here is that since Accumulo's security label model
is trying to enforce role presence, our APIs allow a user to request that
only a subset of their authorizations be used in a given request.

The ability to request only a subset of authorizations on a per-request
basis is needed to implement some common Accumulo use cases (such as a
trusted application filtering for a variety of users in an multi-level
security environment).

As a side effect of this ability, a particular user who is aware of your
negated labels could simply request that only one of their two overlapping
authorizations be considered. In Josh's example, a user could request that
all of their queries carry only the "mailman" authorization and not
whatever "doctor" authorization they had been added to by an administrator
(presuming they held both).


On Mon, Mar 10, 2014 at 10:24 AM, John Vines <> wrote:

> Your case for exclusivity also breaks when you take into account users
> having the intersection of visibilities they have access to and
> visibilities they are requesting to use.
> On Mon, Mar 10, 2014 at 11:00 AM, Philip A Grim II <
>> wrote:
>> Josh Elser said:
>> <snip>
>> Second, the functionality is already present by the lack of providing the
>> label which you want to negate. Categorizing data into static labels tends
>> to be more manageable over using many roles. While enumerating the inverse
>> of a negation is possible, it is valid that the marking may be much larger
>> on disk than a representation using a negation.
>> </snip>
>> I’m having trouble with this – perhaps I’m not thinking of it the right
>> way.
>> How would you handle mutual exclusivity?  So, say I have a cell that I
>> can mark M or F.  If it’s M, people with M can see it.  If it’s F, people
>> with F can see it.  But people with M&F can see it either way, and I don’t
>> want that.  If it’s marked F, I don’t want people with M seeing it.  So
>> (F&!M) makes sense to denote that.  Lacking that, the only way I can see to
>> implement what I want is somehow in application or business logic to make
>> sure nobody gets assigned M and F at the same time…which breaks the model
>> of letting Accumulo enforce visibility.
>> Am I missing something?

View raw message