accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 16:10:07 GMT
On Mon, Mar 10, 2014 at 11:50 AM, Sean Busbey <busbey+lists@cloudera.com>wrote:

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

To safely add not, it seems like we would also need to add the concept of a
minimal authorization set.  Currently an Accumulo user has a maximum set of
authorizations they can query.  However they can choose to use any subset
of this including the empty set.  For exmaple Accumulo user doc has a
maximum authorization set of (doctor, researcher) and a minimal set
(doctor).  So every scan must specify at least 'doctor' or it will fail.

This seems very complicated and easy for users to get wrong.



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