accumulo-user mailing list archives

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

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).

-Sean

On Mon, Mar 10, 2014 at 10:24 AM, John Vines <vines@apache.org> 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 <
> phil@insufficient-light.com> 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?
>>
>
>

Mime
View raw message