accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: "NOT" operator in visibility string
Date Thu, 06 Mar 2014 01:45:08 GMT
What's wrong with the javadoc? The example in the javadoc explicitly
says "dog|!cat" is invalid.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Wed, Mar 5, 2014 at 8:35 PM, Michael Wall <mjwall@gmail.com> wrote:
> Perhaps the javadoc should be updated?
>
> http://accumulo.apache.org/1.5/apidocs/org/apache/accumulo/core/security/ColumnVisibility.html#ColumnVisibility(java.lang.String)
>
> Mike
>
>
> On Wed, Mar 5, 2014 at 8:16 PM, Christopher <ctubbsii@apache.org> wrote:
>>
>> This has been discussed for inclusion in the past. The reason it has
>> not been implemented is that new users with no authorizations yet, a
>> typo in a user's authorizations, or a hiccup in the authorization
>> retrieval system, a minor misconfiguration, or some other thing, could
>> expose data inadvertently. There are risks of this happening anyway
>> (mislabeling data, or assigning incorrect authorizations), but this
>> adds another dimension to those risks, and it's actually much worse
>> than that.
>>
>> Accumulo's visibility labels implement role-based mandatory access
>> controls. Allowing a NOT operator would mean that you have to have
>> *complete* knowledge of your data in order to apply the correct
>> visibility labels in order to restrict access to that data to
>> authorized users. Not only would you have to know what a user is
>> explicitly allowed to see, by role/category or whatever you use
>> authorizations labels to represent, but you also have to know *EVERY*
>> piece of data with a NOT in its label in order to apply it to users in
>> order to restrict their access. (Example: you'd have to know to apply
>> "B" to all restricted users if there's any possibility of data
>> entering the system labeled as "A|!B"). As such, NOT runs contrary to
>> Accumulo's data protection design principle of "default restricted".
>>
>> Without NOT, Accumulo's visibility labeling system is not functionally
>> complete, but it does satisfy the requirements for strict control over
>> data access. However, I empathize with the desire to include such a
>> feature, as there are certain use cases which simply cannot be
>> implemented easily without a functional-completeness. As such, I would
>> personally support your efforts to include a patch to implement it, so
>> long as it was not enabled by default. If you really need this
>> feature, I'd suggest doing the work to make the visibility evaluation
>> pieces pluggable, with a "default restricted" one as the provided and
>> default implementation.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Wed, Mar 5, 2014 at 3:48 PM, joeferner <joe.m.ferner@gmail.com> wrote:
>> > I'm looking at implementing the "NOT" operator in visibility strings. I
>> > actually have it working just need to write some unit tests for it. I
>> > was
>> > wondering if there was any reason why it don't exist now? It looks to be
>> > explicitly called out in the docs "dog|!cat".
>> >
>> > The new HBase also looks to support the "NOT" operator:
>> > https://hbase.apache.org/book/hbase.visibility.labels.html
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> > http://apache-accumulo.1065345.n5.nabble.com/NOT-operator-in-visibility-string-tp7949.html
>> > Sent from the Users mailing list archive at Nabble.com.
>
>

Mime
View raw message